Сводка высокой доступности Redis: репликация Redis master-slave, дозорный кластер, разделенный мозг...

Сводка высокой доступности Redis: репликация Redis master-slave, дозорный кластер, разделенный мозг...

Чем тяжелее, тем удачливее,
Эта статья собрана на GitHubJavaCommunity, Есть обмен интервью, статьи серии анализа исходного кода, добро пожаловать на сбор, как
GitHub.com/cc Ask Me-Contact/Jav…

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

Таким образом, для достижения высокой доступностиRedisКакие варианты высокой доступности предоставляются?

• Репликация Redis master-slave
• Стойкость Redis
• Кластер Стражей
• ...

Redisна основеMasterМного мастер-узловSlaveрежим ведомого узла иRedisМеханизм сохранения для хранения части данных в нескольких экземплярахУвеличение избыточности реплик, и использовать сигнальный механизм для реализации переключения ведущий-резервный.masterПри возникновении неисправности она автоматически обнаруживается иslaveпереключить наmaster, окончательная реализацияRedisВысокая доступность.

Репликация Redis master-slave

RedisРепликация master-slave, один режим библиотеки master-slaveMasterМного мастер-узловSlaveВ режиме ведомого узла копия данных хранится в несколькихSlaveНапример,Увеличение избыточности реплик, когда происходит некоторое время простоя,RedisУслуги по-прежнему доступны.

Однако будут проблемы с несогласованностью данных.Какова согласованность данных набора реплик Redis?

RedisЧтобы обеспечить согласованность копий данных, библиотека master-slave использует метод разделения чтения и записи:

• Операция чтения: как главная библиотека, так и подчиненная библиотека могут выполнять обработку;
• Операция записи: сначала выполняется в главной библиотеке, а затем главная библиотека синхронизирует операцию записи с подчиненной библиотекой.

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

При использовании метода разделения чтения и записи операция записи будет выполняться только в основной библиотеке, а затем синхронизироваться с ведомой библиотекой.Как библиотека ведущий-ведомый синхронизирует данные?

Библиотека master-slave может синхронизировать данные двумя способами:

• Полная синхронизация: Обычно, когда главный-ведомый сервер только что подключен, он сначала выполняет полную синхронизацию.
• Инкрементная синхронизация: Как правило, после завершения полной синхронизации выполняется инкрементная синхронизация, например, сеть между главной и подчиненной базами данных прерывается, а затем выполняется синхронизация данных.

Полная синхронизация

Первый раз между главной и подчиненной библиотекамиПолная синхронизация, который делится на три этапа:

• Когда ведомая библиотека запускается, ведомая библиотека отправляет основную библиотекуpsyncкоманда для синхронизации данных (psyncКоманда содержит: файлы основной библиотекиrunIDи скопировать прогрессoffsetдва параметра),

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

• Когда основная библиотека завершит отправку файла RDB, она также сохранит операцию записи во время отправки файла RDB.replication bufferОтправьте его в подчиненную библиотеку, и подчиненная библиотека повторно выполнит эти операции. Таким образом синхронизируется библиотека master-slave.

Кроме того, чтобы разделить нагрузку основной библиотеки для создания файлов RDB и передачи файлов RDB и повышения эффективности, вы можете использоватьМодель «ведущий-подчиненный-подчиненный» распределяет нагрузку главной библиотеки на создание RDB и передачу RDB в подчиненную библиотеку каскадным образом.

Инкрементная синхронизация

Инкрементная синхронизация на основе кольцевого буфераrepl_backlog_bufferРеализация буфера.

В кольцевом буфере основная библиотека запишет место, куда она записывалаmaster_repl_offset, подчиненная библиотека запишет прочитанную позициюslave_repl_offset, основная библиотека и черезmaster_repl_offsetиslave_repl_offsetРазностные данные синхронизируются с ведомой библиотекой.

Когда сеть между главной и подчиненной библиотеками отключена, главная и подчиненная библиотеки будут продолжать синхронизироваться посредством инкрементной репликации, а главная библиотека будет записывать команды операции записи, полученные во время отключения, вreplication buffer, а также записать эти рабочие команды вrepl_backlog_bufferэтот буфер, затем основную библиотеку и черезmaster_repl_offsetиslave_repl_offsetРазностные данные синхронизируются с ведомой библиотекой.

так какrepl_backlog_bufferЭто кольцевой буфер. Когда буфер будет заполнен, основная библиотека продолжит запись. Что произойдет в это время?

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

При репликации master-slave, помимо несогласованности данных, может быть даже неработоспособность основной базы данных.Redis будет иметь механизм переключения master-slave. Как этого добиться?

Механизм Redis Sentinel

При зависании основной библиотеки операции записи и синхронизации данных Redis выполняться не могут.Чтобы избежать этой ситуации, можно переизбрать новую основную библиотеку из подчиненной библиотеки после зависания основной библиотеки и уведомить об этом клиента.Redis обеспечиваетСторожевой механизм, дозорный — это процесс Redis, работающий в специальном режиме.

Redis будет иметь механизм переключения master-slave, как этого добиться?

Механизм Sentinel является ключевым механизмом для реализации автоматического переключения библиотеки master-slave и в основном делится на три этапа:

• Мониторинг: Процесс Sentinel периодически отправляет команды PING всем основным и подчиненным библиотекам, чтобы проверить, работают ли они в сети.
• Выберите мастер (выберите главную библиотеку): после того, как основная библиотека повесит трубку, часовой выбирает новую главную библиотеку экземпляра подчиненной библиотеки на основе определенных правил и оценок.
• Примечание. Sentinel отправит информацию о новой главной библиотеке другим подчиненным библиотекам, чтобы они могли установить соединение с новой главной библиотекой и выполнить репликацию данных. В то же время дозорный будет передавать информацию о новой основной библиотеке клиентам, чтобы они могли отправить операцию запроса в новую основную библиотеку.

Среди них, как определить, находится ли основная библиотека в автономном режиме во время мониторинга?

Автономное суждение Sentinel об основной библиотеке делится на:

• Субъективный офлайн:Процесс-страж будет использовать команду PING для обнаружения сетевого соединения между собой и главной и подчиненной библиотеками, чтобы определить состояние экземпляра.Если один дозорный обнаружит, что время ожидания ответа главной библиотеки или подчиненной библиотеки на команду PING истекло, то дозорный сначала пометит его как «субъективно в автономном режиме».
• Целевой автономный режим: в кластере Sentinel, основываясь на том факте, что меньшинство подчиняется большинству, большинство экземпляров определяют, что основная база данных была «субъективно отключена», а основная база данных считается «объективно автономной».

Почему существуют два офлайн-состояния: «субъективное офлайн» и «объективное офлайн»?

Так как одномашинный дозорный подвержен ошибочным суждениям, переключатель ведущий-ведомый приведет к ряду дополнительных затрат после ошибочного суждения.Чтобы уменьшить ошибочное суждение и избежать этих ненужных затратКластер Стражей, введение нескольких экземпляров дозорных для совместной оценки может предотвратить ошибочную оценку основной базы данных одним дозорным в автономном режиме из-за его собственных плохих сетевых условий.

Основываясь на принципе подчинения меньшинства большинству, при наличии N дозорных экземпляров лучше всего иметь N/2 + 1 экземпляр, чтобы оценить основную библиотеку как «субъективно отключенную», а затем, наконец, определить основную библиотеку как «объективную автономную». (можно настроить. Установить порог).

Так как же Стражи общаются друг с другом?

Экземпляры Sentinel в кластере Sentinel могут обнаруживать друг друга,на основеRedisПредоставленный механизм публикации/подписки (pub/subмеханизм),

Стражи могут публиковать/подписывать сообщения в основном репозитории, в основном репозитории есть файл с именем "\__sentinel__:hello», через который разные часовые обнаруживают друг друга и общаются друг с другом, и только приложения, которые подписаны на один и тот же канал, могут обмениваться информацией посредством опубликованных сообщений.

Информация о соединении Sentinel 1 (IP-порт) публикуется в "\__sentinel__:hello», на который подписаны Sentinels 2 и 3.

Дозорные 2 и 3 могут напрямую получать из этого канала информацию о соединении дозорного 1. Таким образом формируется кластер дозорных, и каждый дозорный может связываться друг с другом.

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

После того, как было установлено, что основная библиотека отключена, как выбрать новую основную библиотеку?

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

как правилоопределенные условиявключают:

• текущий онлайн-статус подчиненной библиотеки,
• Судя по предыдущему статусу сетевого подключения, черезdown-after-milliseconds * num(Количество отключений), когда количество отключений превышает пороговое значение, оно не подходит для новой основной библиотеки.

некоторые правила включают:

• Приоритет ведомой библиотеки, черезslave-priorityЭлемент конфигурации, установите разные приоритеты для разных подчиненных библиотек, подчиненная библиотека с наивысшим приоритетом имеет более высокий балл
• Ход репликации подчиненной библиотеки, подчиненной библиотеки, наиболее близкой к степени синхронизации старой главной библиотеки, имеет высокий балл и проходитrepl_backlog_bufferОсновная библиотека буферных записейmaster_repl_offsetи из библиотекиslave_repl_offsetРазница минимальный высокий балл
• Идентификационный номер подчиненной библиотеки, подчиненная библиотека с небольшим идентификационным номером имеет более высокий балл.

Все они основаны на выборе ведомой базы данных с наивысшим баллом в определенном раунде определенных правил, а часовой инициирует переключение ведущий-ведомый..

лидер часовой

После выбора новой главной базы данных каждый дозорный не может инициировать переключение ведущий-подчиненный и должен быть выбран в качестве ведущего дозорного Как выбрать ведущий дозорный для выполнения переключения ведущий-подчиненный?

выборыleaderСтражи также избираются «арбитром с голосованием» на основе принципа подчинения меньшинства большинству.

• Когда какая-либо подчиненная библиотека определяет, что основная библиотека «субъективно отключена», она отправляет командуs-master-down-by-addrКоманда посылает сигнал, что хочет быть лидером,
• Другие дозорные отвечают относительно соединения с хостом, Y голосов за и N голосов против них, и если несколько дозорных инициируют запрос, каждый дозорный может проголосовать только за одного из них, а другие могут проголосовать только против него.

Чтобы стать Стражем Лидера, необходимо выполнить два условия:

• Во-первых, получить более половины голосов за;
• Во-вторых, количество полученных голосов также должно быть больше или равно числу в файле конфигурации Sentinel.quorumценность.

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

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

событие	Связанные каналы
Оффлайн-мероприятие в главной библиотеке	+sdown (экземпляр переходит в состояние «субъективно в автономном режиме») -sdown (экземпляр выходит из состояния "субъективно оффлайн") +odown (экземпляр переходит в состояние «объективный офлайн») -odown (экземпляр выходит из состояния «объективно офлайн»)
Новый переключатель основной библиотеки	+ switch-master (изменение адреса основной библиотеки)

Среди них, когда клиент подписывается на сообщение от часового для переключения главной-подчиненной библиотеки, когда главная библиотека переключается, клиентский терминал получит информацию о подключении новой главной библиотеки:

switch-master <master name> <oldip> <oldport> <newip> <newport>  

Таким образом, Sentinel может уведомить клиента о переключении на новую библиотеку.

Основываясь на вышеуказанных механизмах и принципах, Redis обеспечивает высокую доступность, но также несет в себе некоторые потенциальные риски, такие как потеря данных.

проблема с данными

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

• Процесс переключения master-slave, потеря данных из-за асинхронной репликации
• Потеря данных из-за разделения мозга
• В процессе переключения master-slave асинхронная репликация приводит к несогласованности данных

Потеря данных — асинхронная репликация Master-Slave

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

Описание: Данные главной базы данных не были синхронизированы с подчиненной базой данных, в результате происходит сбой основной базы данных и несинхронизированные данные теряются.

Потеря данных — разделенный мозг

Что такое расщепленный мозг? Когда у мастера в кластере происходит сбой сети и он не может связаться с sentinal, sentinal будет думать, что мастер отключен, и sentinal выбирает подчиненное устройство в качестве нового мастера.В это время есть два мастера.

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

Резюме: данные главной базы данных не были синхронизированы с подчиненной базой данных.В результате, главная база данных вышла из строя.После обновления подчиненной базы данных до главной базы данных несинхронизированные данные будут потеряны.

Решения для защиты от потери данных

Потеря данных может быть решена путем разумной настройки параметров min-slaves-to-write и min-slaves-max-lag, например

• min-slaves-to-write 1
• min-slaves-max-lag 10

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

несогласованность данных

В процессе асинхронной репликации master-slave, когда ведомая библиотека заблокирована из-за сетевой задержки или высокой сложности выполнения, синхронная команда выполняется с задержкой, что приведет к несогласованности данных

Решение: Можно разработать внешнюю программу для отслеживания хода репликации между главной и подчиненной библиотеками (master_repl_offsetиslave_repl_offset), отслеживаяmaster_repl_offsetиslave_repl_offsetРазницу стоит знать о ходе репликации, когда ход репликации не соответствует ожидаемым настройкам, клиент больше не будет считывать данные из ведомой библиотеки.

Суммировать

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

Спасибо за ваши лайки, если не нравится ставьте лайк и поддержите
Наконец, WeChat ищет «Ccww Technology Blog», чтобы посмотреть больше статей, и добро пожаловать на волну