Реплика Redis обрабатывает ошибочные строки подключения

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

Было бы признательно, если бы кто-нибудь мог просмотреть мои конфигурации и решить случай, который я считаю сложным.

Конфигурация Redis:

У меня настроено несколько реплик Redis, одна в качестве главной, а другие в качестве подчиненных. Скажем для упрощения:

  • server1: настроен как главный
  • server2 ~ serverN: настроены как ведомые, ссылаясь на server1

Redis sentinel(s) может быть, а может и не быть в этой структуре, потому что я не могу гарантировать, что там будут как минимум серверы.

В моей ситуации гарантированно существует только server1, а серверы со 2 по N — нет.

Среда развертывания веб-приложения:

У меня также есть веб-приложения .NET, развернутые с использованием двух строк подключения: одна для ведущего, а другая для одного из ведомых. Веб-сервисы используют

Строки подключения будут выглядеть так:

  • «server1,password=myredispassword» для мастера Redis
  • "serverN,password=myredispassword" для подчиненного устройства Redis

Конечно, если веб-приложение имеет ведомое соединение для serverN, то serverN гарантированно существует.

Проблемная ситуация (и вопрос):

Теперь я думаю, что возможна ситуация, когда есть упавшая реплика Redis (главная или подчиненная), и мое веб-приложение ссылается на эту упавшую реплику Redis через строку подключения.

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

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


.net redis stackexchange.redis redis-sentinel
person Shavakan    schedule 14.03.2017    source источник
comment
Таким образом, приложение с основной строкой подключения выполняет только запись, а другое с подчиненной строкой подключения только читает?   -  person Atish    schedule 14.03.2017
comment
@Astro Умм, приложение имеет как ведущее, так и ведомое соединения, но оно записывает, используя строку соединения ведущего, и читает, используя строку соединения ведомого устройства. Я думал, что это предполагаемое поведение использования репликации? Мне интересно, что произойдет (и нужно ли мне обрабатывать этот случай), когда ведомое устройство выйдет из строя, а приложение попытается прочитать, или мастер выйдет из строя и приложение попытается записать.   -  person Shavakan    schedule 15.03.2017
comment
В обоих случаях он должен потерпеть неудачу... так как он понятия не имеет, куда подключаться, если одно соединение с одной конечной точкой не работает. Обычно это обрабатывается с помощью дозорного   -  person Atish    schedule 15.03.2017

Ответы (1)


arrow_upward
1
arrow_downward

Эта ситуация может быть лучше обработана с помощью redis sentinel. Ваше приложение подключается к конечной точке Redis Sentinel, которая:

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

  2. Поставщик конфигурации: Sentinel действует как поставщик конфигурации. С помощью строки подключения Sentinel он определяет главный и подчиненный узлы. Он также позаботится о пересылке вашего запроса на чтение на ведомое устройство и на запись на ведущее устройство.

Ваше приложение должно подключаться к конечной точке, как показано ниже: IP: Порт: т.е. 26379

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

Порты Redis и Sentinel должны быть доступны с вашего сервера приложений.

person Atish    schedule 15.03.2017
comment
Спасибо за разъяснение! - person Shavakan; 15.03.2017