Перевести кэш L2 в спящий режим в кластере

Question

Q1:Прав ли я в том, что только эти поставщики поддерживают гибернацию кэша L2 в кластере?

• Терракота для зимней спячки (коммерческая)
• SwarmCache (не выпускался с 2003 года)
• Кэш JBoss 1.x
• Кэш JBoss 2

Q2:Существуют ли какие-либо альтернативы спящему кешу L2?(Может быть, какое-нибудь кэширование базы данных?)

Answer 1

Q1.EhCache работает очень хорошо, как распределенный кэш Hibernate L2.Мы используем это для нашего проекта.

---

Вопрос 2.Возможно несколько кэшей.

• Все базы данных уже выполняют большое внутреннее кэширование, так что не беспокойтесь об этой части.

Однако проблема с кешем базы данных заключается в том, что физически он находится на сервере базы данных , поэтому каждый запрос включает сетевой вызов (задержка, пропускная способность ..).В этом весь смысл кэшей на сервере приложений .

---

• Кэш-память Hibernate L2 имеет некоторые особенности:
  • очень прост в работе (нет кода, мало настроек)
  • концептуально на уровне сущности (который довольно мелкозернистый, иногда нам нужно кэшировать большие зерна, чтобы делать меньше запросов к базе данных),
  • работа по идентификатору или коллекции (например, кэширование результата запроса по умолчанию отключено, поскольку невозможно сделать его полезным в общем случае).

---

• Когда режим гибернации L2 не подходит, мы используем ту же библиотеку EhCache для кэширования данных (которые не совсем являются сущностями).Примеры вариантов использования:
  • когда таблица находится большой (рекордная длина и количество), использование памяти не позволило бы кэшировать его полностью, но кэширование только трех полей для всех записей - это нормально.Возможно, к этим полям обращаются часто или они неизменяемы...
  • когда у нас есть много обращений на чтение к кэшу, и каждое из них запускает вычисление (в кэше L2) учитывая объекты, которые у нас есть :результат вычисления может быть сохранен в кэше.(типичный пример, когда для вычисления требуются сведения из других таблиц, но эти сведения не используются в конечном результате, поэтому кэш не хранит эти сведения)
  • когда объекты в таблице логически сгруппированы по Категории, и мы хотим запрашивать и кэшировать по одной категории за раз, вместо обычной политики кэширования L2, которая представляла бы собой одну сущность за раз.

В распределенном контексте это часто приводит к аннулированию категории в то время, когда изменяется одна из их сущностей, которая функционально логично для нас (и важно для производительности, поскольку в противном случае нам пришлось бы аннулировать все эти объекты ;это связано с тем, что кэш делает недействительным целую область или определенный объект, но в промежутках между ними вам приходится выполнять цикл, что плохо сказывается на производительности)

И другие , я уверен ...

Таким образом, этот случай не имеет тесного отношения к базе данных, в нем обычно не хранятся наши объекты Hibernate.Мы помещаем его на бизнес-уровень (а не в систему доступа к данным или Dao), делаем доступным непосредственно для бизнес-кодов.Обратите внимание, что для нас это не прозрачный кеш, а вызов явной бизнес-службы (отвечающей за этот кеш :загружая его, если данные отсутствуют, делая недействительным по мере необходимости), который выполняет операции или доставляет значения.

Забавная проблема с потоками в этом кэше :поскольку к этому кешу обращаются наши сотни веб-потоков, он должен быть потокобезопасным.Вы, вероятно, знаете, почему потокобезопасное значение либо является неизменяемым, либо клонируется при каждом вызове (что часто является проблемой производительности).Таким образом, все наши бизнес-кэши используют неизменяемые объекты, и производительность у них отличная.

Answer 2

Вы также можете использовать [Infinispan (эволюция JBoss Cache) в качестве поставщика кэша 2-го уровня!][1]

[1]:Видеть http://infinispan.blogspot.com/2009/10/infinispan-based-hibernate-cache.html

Answer 3

У EhCache есть распределенный режим, но я не уверен, поддерживается ли он в Hibernate.Хотя я не понимаю, почему это не должно работать.

Вы пропустили JBossCache 3 по какой-то конкретной причине?

Answer 4

спящий режим-Redis lib будет идеальным выбором.Это кеш на основе Redis.

Почему Редис?он невероятно быстр, работает в облаке и имеет готовое облачное решение, например AWS Эластикаче, поэтому вам не нужно управлять им самостоятельно.