Ehcache с дизайном сохраняемости DB
Я разрабатываю приложение, которое должно потреблять оперативные данные из нескольких источников и периодически отчитываться о них. Потребленные данные будут добавлены в кэш Ehcache, и отчеты будут запрашивать их. После того, как живые данные потребляются, они должны быть сохранены только для целей восстановления. Если приложение перезапустится, оно загрузит кэш с историческими данными из БД перед подключением к источникам живых данных (которые ставят новые данные в очередь).
Я склоняюсь к тому, чтобы реализовать его как cache-as-sor с помощью кэширования JDBC:
1. Получение данных из источника
2. Сохраниться в DB
3. Добавить в кэш
4. Подтвердите получение с источником
С 2-4 завернутыми в транзакцию JTA.
Я также заглянул в Hibernate с Ehcache в качестве кэша 2-го уровня, но это не кажется подходящим.
Я относительно новичок в Ehcache, поэтому хотел бы получить несколько советов по правильному дизайну.
3 ответа:
Для сохраняемости, вместо того, чтобы делать "кэш-сторону", вы, вероятно, хотели бы настроить свои кэши для использования чтения через и некоторые записи кэша (либо через запись, либо после записи). Вы можете прочитать об этом здесь: http://ehcache.org/documentation/user-guide/concepts#cache-as-sor Теперь я бы избегал JTA, так как боюсь, что накладные расходы могут быть чрезмерными (за исключением тех случаев, когда вам действительно нужно восстановление транзакций XA), и скорее выбрал отказоустойчивый подход. Если вы выберете асинхронную персистентность (write-behind), кластеризация кэша с помощью Terracotta (очередь WriteBehind автоматически будет постоянной, восстанавливаемой и даже HA, если доступно несколько узлов) - это один из подходов к обеспечению того, чтобы каждый элемент был записан в базовый SoR... Все зависит от ваших потребностей, я думаю.
Ehcache позволит вам начать с одного узла, некластеризованного подхода, просто используя кэши для чтения и записи, которые вы можете вырастить и настроить для удовлетворения вашего SLA. По мере роста данных вы будете возможность перехода к кластеризованным кэшам и асинхронным записывающим устройствам (если записи станут проблемой) или увеличения размеров кэша (если чтение останется проблемой). Очевидно, что вы должны измерить (или, по крайней мере, знать, какие узкие места вы предвидите) и выбрать соответственно. Но размещение кэша перед вашей СУБД-это распространенный и хорошо понятный шаблон для масштабирования доступа чтения (и записи) к этим "медленным" хранилищам...
Если вы хотите иметь данные в кэше, гибернация выглядит как перебор. Все, что вам нужно, это JDBC, как для реализации загрузчика кэша для инициализации кэша, так и для периодического сохранения данных в базе данных. Или просто настройте кэш, чтобы он сохранялся на диске.
Тогда Ehcache + Hibernate не является решением. То, что вы описываете здесь, является асинхронной системой обработки событий, в которой один из слушателей ожидает, что "событие обработано успешно" сохранится.
Базы данных NoSQL являются гораздо лучшим вариантом в этом случае, если только вам не нужно строго полагаться на реляционную базу данных.