Есть ли способ автоматически обнаруживать IP-адрес нового узла кластера в Redis Cluster с Lettuce? - PullRequest
Новая
       128

Есть ли способ автоматически обнаруживать IP-адрес нового узла кластера в Redis Cluster с Lettuce?

0 голосов
/ 05 августа 2020

У меня есть кластер Redis (3 главных и 3 подчиненных) , работающий внутри кластера Kubernetes . Кластер предоставляется через Kubenetes-Service (Kube-Service) .

У меня есть сервер приложений, подключенный к Redis Cluster (используя Kube-Service как URI) через клиент Lettuce java для Redis. У меня также есть следующие параметры клиента, установленные для объекта подключения Lettuce: 

ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
              .enablePeriodicRefresh(Duration.ofMinutes(10))
              .enableAllAdaptiveRefreshTriggers()
              .build();

ClusterClientOptions clusterClientOptions = ClusterClientOptions.builder()
              .topologyRefreshOptions(topologyRefreshOptions)
              .autoReconnect(true)
              .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS)
              .build();
redisClient.setOptions(clusterClientOptions);

Теперь, когда я тестирую эту настройку, убивая (pods) моего мастера Redis, Kubernetes выполняет свою работу. путем перепланирования нового модуля. Но у нового модуля новый IP-адрес, и салат-латук его никогда не обнаруживает. Как салат справляется с повторным открытием? Похоже, что logi c выше для топологии refre sh больше не выполняет поиск DNS для новых IP-адресов.

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

Лучшее

1 Ответ

0 голосов
/ 06 августа 2020

Предоставлено первым комментарием к указанному выше вопросу.

Итак, я смог решить эту проблему следующим образом.

  • Вышеуказанная настройка для клиента с данными вариантами хорошо. Однако мне пришлось установить disconnectedBehavior на ACCEPT_COMMANDS. Это гарантировало, что клиент продолжит взаимодействовать с Redis для операций во время аварийного переключения.
  • В результате этого непрерывного принятия операций для первого READ или WRITE, которые поступают на клиент после успешного аварийного переключения. выбрал новый мастер, клиент правильно вернет новый IP-адрес нового узла. С этого момента клиент знает новый IP-адрес для слотов, удерживаемых отказавшим узлом.

Это ленивый подход к согласованию при следующей попытке ЧТЕНИЯ или ЗАПИСИ. Но это работает, и я считаю, что этого достаточно. Я не уверен, есть ли лучшие способы справиться с этим.

...