Методы распределенной персистентности в Karaf с Cellar

Question

Я недавно изучал использование Apache Karaf Cellar, чтобы создать распределенное приложение. Это выглядит многообещающе, но у меня проблема с поиском стратегии сохранения, которая идет, как с распределенным мышлением.

Подвал имеет распределенную память, но мне нужно, чтобы все мои узлы сохраняли данные на диске упорядоченным способом.

Желательно, чтобы я хотел хранить хранилище постоянства рядом с каждым экземпляром Karaf, который может сохраняться и извлекать объекты и синхронизировать между собой. Единственный способ, который я нашел для этого, - создать экземпляр MongoDB вместе со всеми моими ошибками Karaf и собрать их в replica set. Есть несколько недостатков в этом подходе, тем более, что в нем есть инструкции по добавлению новых экземпляров MongoDB в набор.

SO: Есть ли способ OSGi для сохранения на жестком диске синхронизированного образа? Кажется, я не могу найти.

Answer 1

Для решения этой проблемы нет «надлежащего способа OSGi». Но с данным стеком технологий вы уже посмотрели, что это возможно.

я «просто» хотят, чтобы хранилищу жить внутри контейнера, так что все может быть установлен и настроен как один

В этом случае я бы сказал Apache Karaf + Apache Karaf Cellar в комбинации с уже используемая Hazelcast Map of Cellar - это решение для вас. В любом приложении, запущенном внутри этого сценария, вы можете использовать предоставленный экземпляр Hazelcast. Который гарантирует, что все ваши пользовательские данные синхронизируются в режиме «hazelcast».

В конце концов, для использования некоторых методов/инструментов, которые будут выполняться в любой среде, необходимо решить некоторые проблемы, связанные с распределением определенных данных между различными узлами.
В этом случае я бы предложил использовать Cellar и Hazelcast, так как это легко использовать. Но могут быть и другие доступные решения, о которых я не знаю сейчас.

EDIT: Чтобы иметь распределенную систему, которая делает сохранение данных из любого узла, либо необходимо перестроить существующие методы, как Кассандра, или просто использовать базу данных Cassandra.

Другим способом было бы иметь разные группы кластеров с подвалом, который состоит только из Службы, которая ведет переговоры с базой данных, эта служба будет предоставлять объекты JTO из этой базы данных. Эта услуга может быть распространена среди других групп кластеров с помощью механизма Cellar (Remote Services). Оттуда разговор с одной БД может быть достигнут путем ссылки на службу OSGi для хранения данных в базе данных с любого узла, и фактически эти службы доступны только на одном узле из другой группы кластеров.

Answer 2

Параллельность в этом случае должна обрабатываться программно. Существующие объекты могут быть заблокированы с помощью карты hazelcast, как описано Achim. Новые объекты для сохранения зависят от вашего исходного интерфейса/услуги (WebService-Request, File-Consum и т. Д.). Только для использования файлов вы должны убедиться, что файл обрабатывается только один раз.

механизмы репликации для кластеров база данных покрываются поставщиками баз данных (даже по MySql (;)