Hibernate - кластерный кеш и обновление версий классов

Question

Мы используем Ehcache в качестве L2-кэша для Hibernate в кластере. Поскольку мы обновляем серверы один за другим, чтобы избежать простоев, в какой-то момент возможно, что в кластере один сервер использует более старую версию кода, а другой - обновленную версию.

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

Я не могу остановить это на уровне Ehcache. Я думал о настройке serialVersionUID для моих классов сущностей, но это не будет работать с этими массивами более низкого уровня.

Как я могу указать Hibernate, что версия сущности изменилась и значение из кэша НЕ должно загружаться?

Answer 1

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

Даже если бы вы могли оценить несовместимость формата объекта и его кэшированной версии, а не загружать его из кэша, в конечном итоге вы получите то, что некоторые машины будут читать из / записывать в кэш, а некоторыебудет идти прямо к базе данных, что приведет к непоследовательному доступу к данным, и так далее, и так далее.По сути, этот подход - червячная банка.

Существует лучшее решение .Шаги включают:

1. Отключите половину кластера от сети.Вы можете использовать управление коммутатором или балансировщиком нагрузки или любые другие доступные средства.
2. Снять эту половину, обновить ее, поднять.
3. Подключить ее обратно.
4. Отключитьсекунда.
5. Повторите # 2 и # 3.

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

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

Надеюсь, это поможет.

Слава Имешев

Cacheonix: надежный распределенный кэш Java