Зачем нужен Sentinel Mode

1. Опираясь только на схему постоянства, сервис не может быть восстановлен после отключения сервера.
2. Используя репликацию master-slave, после того, как главный узел отключится, вы можете вручную переключить подчиненный узел на
   master, но аварийное переключение не может быть выполнено автоматически

Страж

Основная функция

1. Мониторинг: Sentinel будет постоянно проверять, правильно ли работают ваши главные и подчиненные узлы.
2. Уведомление: если есть проблема с отслеживаемым экземпляром Redis, Sentinel может уведомить системного администратора или другие программы через API (pub).
3. Автоматическое переключение при отказе: если мастер отключается, Sentinel запустит аварийное переключение, подчиненное устройство под ведущим будет выбрано в качестве нового главного, а другие подчиненные устройства начнут репликацию нового главного. Приложение может обновить новый главный адрес через механизм уведомлений службы Redis.
4. Поставщик конфигурации: клиенты могут использовать Sentinel в качестве авторитетного издателя конфигурации для получения последнего главного адреса. В случае аварийного переключения кластер Sentinel уведомляет клиентов о новом главном адресе и обновляет конфигурацию Redis.

Основная конфигурация

Sentinel Monitor: отслеживаемый главный узел Redis.
Sentinel — это поставщик конфигурации Redis, а не прокси.Клиент получает конфигурацию узлов данных только от Sentinel, поэтому ip здесь должен быть доступен клиенту Redis.
Шаблон для настройки Sentinel предоставляется в исходном коде Redis: sentinel.conf

Страж начинает

$ redis-server sentinel.conf --sentinel
1

1. Инициализировать обычный сервер Redis
2. Загрузите специфичную для Sentinel конфигурацию, такую ​​как таблица команд, параметры и т. д. Sentinel использует таблицу команд, функции и другие конфигурации в sentinel.c, общие
   Redis использует конфигурацию в redis.c
3. Помимо сохранения общего состояния сервера, Sentinel также сохраняет состояние, связанное с Sentinel.

Подготовить

Sentinel и master: Sentinel отслеживает мастер и обнаруживает другие Sentinel и ведомые устройства через него.
Установите два асинхронных сетевых подключения:

командное соединение: используется для отправки команд на узел основных данных Redis, например, с помощью команды INFO, чтобы узнать:

• Собственная рабочая информация мастера используется для обновления локального главного словаря (эта структура данных также используется в словаре, используемом в реализации Redis Hash).

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

Подключение по подписке:подпискаsentinelКанал :hello, используемый для обнаружения других Стражей, информация в канале включает в себя:

• Собственная информация Sentinel (IP, порт, RunID, эпоха)
• Информация о контролируемом главном узле (имя, IP, порт, эпоха)
  

Sentinel и ведомый: Sentinel автоматически обнаруживает ведомого

1. Sentinel получает информацию обо всех ведомых устройствах после отправки команды INFO на главный узел.
   
2. Sentinel устанавливает командное соединение и соединение по подписке с ведомым устройством.
   

Между стражами: автоматический механизм обнаружения

1. Sentinel использует механизм pub/sub (публикация/подписка) для подписки на данные каждого главного и подчиненного узла данных.
   sentinel:hello для автоматического обнаружения других дозорных узлов, которые также контролируют унифицированный мастер
2. Sentinel идет каждую 1 секундуsentinel:hello отправляет сообщение, содержащее последний мастер, который он поддерживает в данный момент.
   конфигурация. Если дозорный обнаружит, что его версия конфигурации ниже, чем полученная версия конфигурации, он обновит свою основную конфигурацию новой конфигурацией.
3. Установите командное соединение с обнаруженным Sentinel, а затем обменяйтесь представлениями об основном узле данных через это командное соединение.

монитор

1. Регулярно отслеживайте узлы данных Redis.
   1. Каждый часовой отправляет команды INFO на главный и подчиненный узлы каждые 10 секунд.
   2. Каждые 2 секунды каждый дозорный проходит через канал мастер-узла (названный какsentinel:hello) обмен информацией (pub/sub), информация включает в себя:
   3. Каждый дозорный отправляет команду PING другим дозорным, а также ведущим и ведомым устройствам Redis каждую 1 секунду для обнаружения сердцебиения в качестве основы для оценки выживания узла.
2. Субъективный офлайн и объективный офлайн (обнаружена неисправность)
   1. Субъективно недоступен (SDOWN): текущий экземпляр Sentinel считает службу Redis «недоступной». Sentinel не получает допустимый ответ (+PONG, -LOADING или -MASTERDOWN) в течение 30 с (вниз после миллисекунд) после отправки сообщения на главный узел данных Redis, Sentinel пометит мастер как отключенный (откройте SRI_S_DOWN флагов в отметке основной структуры)
   2. Объективно отключен (ODOWN): Несколько экземпляров Sentinel считают, что мастер находится в состоянии SDOWN, тогда мастер будет в это время находиться в состоянии ODOWN. кластер и будет включен механизм аварийного переключения. Отправить на другие дозорные узлы
   Сообщение Sentinel is-master-down-by-addr запрашивает статус узлов данных и знает, что узлы Sentinel, достигшие числа кворума, считают, что узлы данных отключены.

иметь дело с

Выборы стража (на основе алгоритма Raft), выбор лидера

Голосование: изменить локального лидера и лидера_эпохи

1. Для тех, кто уже проголосовал, личность становится Подписчиком, и никакие выборы не будут проводиться в течение 2-кратного времени отработки отказа (время отработки отказа по умолчанию составляет 3 минуты); те, кто не проголосовал, становятся Кандидатами, и выполняется шаг 2.
2. Состояние аварийного переключения обновления — начало, эпоха + 1, а время ожидания обновления — случайное время в пределах 1 с.
3. Отправьте команду is-master-down-by-addr другим узлам, чтобы запросить голосование. Команда принесет свою эпоху
4. 2-кратное время аварийного переключения для выборов

Отличие алгоритма выборов Sentinel от Raft:

1. Выборы проводятся каждый раз, когда требуется отказоустойчивость
2. Добавлен параметр кворума, и количество голосов, требуемое Кандидатом, должно не только превышать половину, но и достигать значения, настроенного параметром кворума.
3. Лидер не будет посылать сообщение о том, что он стал лидером, другим Стражам, а другие Стражи ждут, пока лидер рабит от раба
   После того, как мастер выбран, после того, как будет обнаружено, что новый мастер работает нормально, идентификация объекта в автономном режиме старого мастера будет удалена, поэтому нет необходимости входить в процесс аварийного переключения.
   Уведомление:
   1. Sentinel не может выполнять автоматическую отработку отказа, если только несколько процессов Sentinel работают нормально.
   2. В нормальных условиях нечетные часовые должны быть настроены, чтобы избежать одинакового количества голосов и конкуренции при переключении.
   Появляются два узла, конкурирующие в процессе голосования
   

Аварийное переключение (переключение главного узла данных Redis)

Мастер Sentinel выбирает соответствующий ведомый Redis, чтобы стать мастером

Критерии выбора ведомого:

1. Здоровые узлы:

• онлайн
• Недавно успешно установили связь (ответил на команду PING в течение 5 секунд)
• Данные относительно новые (время отключения от мастера не должно превышать 10*down-after-миллисекунд)
• Ведомый узел с наивысшим приоритетом лава (приоритет ведомого узла)
• Ведомый узел с наибольшим смещением управления (наиболее полная копия)
• Выберите подчиненный узел с наименьшим runId (запустите самый ранний узел)

2. Выполните команду SLAVEOF no one (не будут удалять существующие данные, но больше не будут принимать новые изменения данных от главного узла), чтобы сделать его новым главным узлом. Sentinel отправляет ему INFO-команды каждую секунду, пока не станет мастером.

3. Отправьте команду SLAVEOF new master оставшимся подчиненным узлам, чтобы сделать их подчиненными узлами нового главного узла.

4. Разрешить оставшимся ведомым копировать данные нового ведущего. Путем настройки дозорных параллельных синхронизаций (sentinel.conf) указывается количество ведомых узлов, которые каждый раз инициируют операцию копирования на новый главный узел. Чем больше значение параллельных синхронизаций, подчиненный узел.Чем быстрее завершается репликация, тем больше нагрузка на сеть и нагрузку на жесткий диск главного узла, и подчиненный недоступен в процессе загрузки rdb, отправленного мастером.

5. Обновите исходную конфигурацию главного узла как подчиненного узла и продолжайте обращать на это внимание.Как только узел вернется в нормальное состояние, ему будет дано указание скопировать новую информацию о главном узле.

6. После того, как вся работа по аварийному переключению будет завершена, Leader Sentinel отправит сообщение +switch-master и одновременно сбросит мастер.Операция сброса освободит все подчиненные объекты исходного мастера и другие объекты Sentinel, прослушивающие master, а затем создайте новый подчиненный объект
Может ли ведомое устройство возвращать данные клиенту во время аварийного переключения, зависит от устаревших данных ведомого устройства (redis.conf).

7. Продолжайте следить за старым хозяином и установите его в качестве ведомого нового хозяина, когда он вернется в сеть.

Выполнение мастера отработки отказа Sentinel в Sentinel может заставить дозорный узел выполнить отработку отказа, а не выбирать с другими узлами.

Недостатки стража

1. В режиме Sentinel операции записи по-прежнему могут выполняться только на узле основных данных, предоставленном Sentinel, и не могут быть сбалансированы по нагрузке.
2. Во время персистентности главный узел блокируется очисткой диска, и процент успешных запросов на обслуживание снижается.
3. Емкость хранилища подчиненного узла ограничена одной машиной.
4. Проблема с разделами: исходный мастер redis 3 отключается от redis 1 и redis 2. В это время redis 1 и redis 2 выполняют аварийное переключение, достигая большинства и выбирая redis 1 в качестве мастера. Таким образом, и redis 1, и redis 3 могут принимать запросы на запись, но данные не могут быть синхронизированы, и данные несовместимы.
   

Почему бы не использовать кластерный режим (Cluster)

1. Клиент должен внедрить Smart Client для выполнения перенаправления и других задач.
2. Ограничение на пакетную операцию, не поддерживает запросы между слотами, поэтому поддержка пакетной операции неудобна
3. Поддержка транзакционных операций с ключами ограничена. Она поддерживает только транзакционные операции с несколькими ключами на одном узле. Когда несколько ключей распределены по разным узлам, функция транзакций не может быть использована.
4. В качестве минимальной детализации разделения данных Key не может сопоставлять большой объект значения ключа, такой как хэш, список и т. д., с разными узлами.
5. Несколько пространств баз данных не поддерживаются. Redis на одном компьютере может поддерживать до 16 баз данных. В режиме кластера можно использовать только 1 пространство базы данных, а именно db 0

Ссылаться на

1. Redis Sentinel Documentation
2. Глубокое обучение Redis (4): Sentinel
3. Дизайн и реализация Redis
4. Redis Deep Adventure: основные принципы и практика применения

От: Лю Цун

Смотрите здесь маленьких друзей, если вам понравилась эта статья, не забудьтеВперед, в избранное, взаимодействие с помощью сообщений!

Если у вас есть какие-либо вопросы по статье, пожалуйста, свяжитесь со мной в области сообщений~

Я недавно собрал кое-что новоеДанные Java, в том числе личный обмен, пробные тестовые вопросы и видеогалантерея, если вам это нужно, пришлите мне личное сообщение!

Что в Канканге для вас: