Как обеспечить продолжение работы Java-клиентов, если весь кластер hazelcast не работает

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

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

  1. Кто-то перепутал конфигурацию hazelcast и карта в кластере увеличивается до тех пор, пока у нас не будет OOM (было такое на тестовой системе).
  2. Возникла проблема с сетевыми картами/аппаратными средствами, которая временно прерывает соединение с кластером.
  3. Ребята из ОП перенастроили брандмауэр и случайно заблокировали некоторые необходимые порты, что бы там ни было.
  4. Что угодно

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

Во время моих текущих тестов приложение полностью перестало работать, потому что после определенных повторных попыток клиенты отключаются от кластера, и спящий кеш 2-го уровня больше не работает. Поскольку мы используем hazelcast во всей экосистеме, это почти мгновенно убьет 40 клиентов Java.

Таким образом, мне интересно, как мы могли бы добиться того, чтобы приложения все еще работали медленнее, когда кластер не работает. Наш текущий подход заключается в переключении на локальный кеш ehcache, но я думаю, что для этой проблемы также должно быть решение hazelcast?


java hibernate hazelcast failover failovercluster
person u6f6o    schedule 09.01.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

На вашем месте я бы использовал LocalSessionFactoryBean и установите cacheRegionFactory в Spring Bean, который может делегировать вызов либо Hazelcast, либо NoCachingRegionFactory, если сервер Hazelcast не работает.

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

person Vlad Mihalcea    schedule 09.01.2015
comment
Может быть, я думаю в неправильном направлении, но афаик. RegionFactory существует только для создания различных регионов (Entity, Collection, QueryResults, Timestmaps), а hibernate использует его при запуске и завершении работы SessionFactoryImpl. После того, как регионы построены, hibernate выполняет итерацию по регионам и получает стратегии доступа к регионам. - person u6f6o; 09.01.2015
comment
Это означает, что простая замена региона не решит проблему, поскольку спящий режим по-прежнему будет использовать неправильные стратегии доступа внутри для доступа к различным регионам. В нашем текущем подходе мы создаем оболочку, которая использует регионы ehcache и hazelcast и переключается, если кластер не работает, но это довольно грязно, и я действительно хотел бы использовать только hazelcast. - person u6f6o; 09.01.2015
comment
Я не думаю, что это грязно. Любая другая реализация тоже может дать сбой. У вашего поставщика кеша может закончиться память или место на диске, и исключение будет распространено на код вашего приложения. Таким образом, резервный подход является лучшим подходом для обеспечения высокой доступности. - person Vlad Mihalcea; 09.01.2015
comment
@ u6f6o Я тоже столкнулся с той же проблемой. Смогли ли вы решить это. Можете ли вы поделиться образцом кода, пожалуйста. - person Art; 18.07.2018
comment
Также я не думаю, что LocalSessionFactoryBean работает с spring dataJPA, поскольку для этого требуется EntityManagerFactory... - person Art; 18.07.2018
comment
@Art: В конце концов мы выбрали другой подход. Вместо совместного использования данных по всему кластеру мы поддерживали локальный кеш, который был аннулирован событиями, вызванными Hibernate и Hazelcast. Вы можете думать об этом как о ConcurrentHashMap внизу с типичной механикой LRU и LFU и событиями сверху, которые вытесняют определенные записи на карте. Это сопряжено с некоторым риском несогласованности, поскольку вы можете пропустить определенные события/инвалидации, но, с другой стороны, данные почти никогда не менялись, поэтому мы могли справиться с этим. Кроме того, режим работы был одноранговым, а не ведущим и ведомым. - person u6f6o; 18.07.2018
comment
Что означает, что вы использовали hazelcastLocalRegion? Вы не смогли добиться того, что задали в вопросе? - person Art; 20.07.2018