Ehcache с сохранением БД

Question

Я разрабатываю приложение, которое должно использовать живые данные из нескольких источников и периодически отчитываться о них.Потребленные данные будут добавлены в кэш Ehcache, и отчеты будут запрашивать их.После того, как оперативные данные израсходованы, их необходимо сохранить только для целей восстановления.Если приложение перезапускается, оно заполняет кэш историческими данными из БД, прежде чем подключаться к действующим источникам данных (которые ставят в очередь новые данные).

Я склоняюсь к тому, чтобы реализовать его как кеш-сортировщик сКеширование JDBC:
1. Получение данных из источника
2. Сохранение в БД
3. Добавление в кэш
4. Подтверждение получения с источником

с 2-4, завернутыми вТранзакция JTA.

Я также рассмотрел Hibernate с Ehcache как кэш 2-го уровня, но это не кажется подходящим.

Я относительно новичок в Ehcache, поэтому хотел бы получить несколько советов поправильный дизайн.

Answer 1

Для сохранения, а не для «кэширования в стороне», вы, вероятно, захотите сконфигурировать свои кеши для использования чтения и сквозной записи (или для записи, или для записи).Вы можете прочитать об этом здесь: http://ehcache.org/documentation/user-guide/concepts#cache-as-sor Теперь я бы избегал JTA, так как боюсь, что накладные расходы могут быть чрезмерными (за исключением случаев, когда вам действительно нужно восстановление транзакций XA), и скорее выберу отказоустойчивый подход.Если вы выберете асинхронное постоянство (с обратной записью), кластеризация кеша с помощью Terracotta (очередь WriteBehind будет автоматически постоянной, восстанавливаемой и даже HA, если доступно несколько узлов) - это один из способов обеспечения записи каждого элемента в базовыйSoR ... Все в зависимости от ваших потребностей, я думаю.

Ehcache позволит вам начать с одного узла, некластеризованного подхода, просто используя кэши для чтения и записи, которые вы могли бы увеличить и настроить в соответствии с вашим SLA.По мере роста данных вы сможете перейти к кластеризованным кэшам и асинхронным модулям записи (если записи станут проблемами) или увеличить размеры кэша (если чтение остается проблемой).Очевидно, вы должны измерить (или хотя бы знать, какие узкие места вы предвидите) и сделать соответствующий выбор.Но размещение Cache перед вашей RDBMS является распространенным и хорошо понятным шаблоном для масштабирования доступа для чтения (и записи) к этим «более медленным» хранилищам ...

Answer 2

Тогда Ehcache + Hibernate не является решением.Здесь вы описываете асинхронную систему обработки событий, в которой один из слушателей ожидает «событие успешно обработано» для сохранения.

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

Answer 3

Если вы хотите хранить данные в кеше, Hibernate выглядит как перебор. Все, что вам нужно, это JDBC, как для реализации загрузчика кэша для инициализации кэша, так и для периодического сохранения данных в базе данных. Или просто настройте свой кеш для сохранения на диске.