предисловие

Только лысина может стать сильнее

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

• Изучите Redis с Zero Single Row [бронза]
• Изучите Redis с нуля, одиночная строка [серебро]
• Изучите Redis с нуля, одиночная строка [золото]

В этой статье в основном говорится оРепликация Redis master-slave. Поскольку у кластера Redis много очков знаний, есть несколько статей о платине~

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

1. Архитектура «ведущий-ведомый»

1.1 Почему архитектура master-slave

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

Потому что, если у Redis только один сервер, он будет увеличиваться с запросом:

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

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

Для реализации нашего сервисавысокая доступность, эти серверы Redis можно превратить вМастер-рабУправлять

Совет: автор Redis переименовал архитектуру Master/Slave в Master/Replica.

1.2 Особенности архитектуры ведущий-ведомый

Давайте посмотрим на особенности архитектуры master-slave в Redis:

• хозяинСервер отвечает за получениеНапишитепросить
• отСервер отвечает за получениечитатьпросить
• Данные с сервера отправляются главным серверомкопироватьмимо. Данные master-slave серверапоследовательныйиз

архитектура «ведущий-ведомый»выгода:

• Разделение чтения-записи (главный сервер отвечает за запись, а подчиненный за чтение)
• Высокая доступность (ведомый сервер зависает, другие подчиненные серверы могут продолжать получать запросы, не влияя на работу службы)
• обрабатывать больше параллелизма (на ведомое устройствоможет получать запросы на чтение, читайте QPS и поднимайтесь)

Помимо вышеперечисленных форм, архитектура master-slave также имеет следующие (но менее используемые):

2. Функция копирования

Одна из характеристик архитектуры master-slave: данные главного сервера и подчиненного серверапоследовательныйиз.

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

В Redis пользователи могут позволить одному серверу реплицировать другой сервер, выполнив команду SALVEOF или установив параметр salveof. Мы называем реплицированный сервер главным сервером, а сервер, который реплицирует главный сервер, называется главным сервером, который называется подчиненным сервером ( бальзам)

2.1 Конкретная реализация функции копирования

Функция копирования разделена на две операции:

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

раб хозяинаСинхронизацию можно разделить на два случая:

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

До Redis 2.8 при копировании этой части после отключения не хватало толькочасть данных, но пусть master-slave серверПовторно выполните команду SYNC, этот подход очень неэффективен. (Поскольку выполнение команды SYNC ставитвсе данныеСинхронизировать снова, а не только потерянные данные)

Далее подробно рассмотрим, как реализована функция репликации после Redis 2.8:

2.1.1 Предварительная работа для тиражирования

Сначала давайте посмотрим наПредварительная работа:

• Установите IP и порт главного сервера с сервера
• Установить сокет-соединение с основным сервером
• Отправьте команду PING (проверьте, нормально ли чтение и запись сокета для связи с основным сервером)
• Аутентификация (проверьте, установлена ​​ли соответствующая конфигурация аутентификации)
• Подчиненный сервер отправляет информацию о порте на главный сервер, а главный сервер записывает порт прослушивания.

Как упоминалось ранее, до Redis 2.8 синхронизация повторно выполняла команду SYNC после отключения, что оченьнеэффективныйиз. Давайте посмотрим, как выполнить синхронизацию после Redis 2.8.

Начиная с Redis версии 2.8, используйте команду PSYNC дляальтернативаКоманда SYNC выполняет операцию синхронизации при копировании.

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

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

Давайте сначала посмотримвсеКак реализована ресинхронизация:

• Ведомый отправляет команду PSYNC ведущему
• Главный сервер, получивший команду PSYNC, выполняет команду BGSAVE в фоновом режиме.Создать RDB-файл. и использоватьбуферзаписывать все казни с этого моментанаписать команду.
• Когда команда BGSAVE главного сервера выполнена, отправьте сгенерированный файл RDB на подчиненный сервер,Получение и загрузка файлов RBD с сервера. Обновляет состояние собственной базы данных до состояния, в котором она находилась при выполнении команды BGSAVE с мастером.
• Главный сервер будетКоманда записи отправлена ​​ведомому устройствуи выполнить эти команды записи с сервера, чтобы добиться возможной согласованности данных.

2.1.2 Частичная повторная синхронизация

Далее посмотримчастьПовторная синхронизация, частичная повторная синхронизация позволяет нам повторно подключаться после отключенияНужно только синхронизировать отсутствующие данные(Вместо синхронизации всех данных до Redis2.8) это логично!

Функция частичной повторной синхронизации состоит из следующих частей:

• ведущий-ведомый серверсмещение копии
• главный серверКопировать буфер невыполненной работы
• Идентификатор запущенного сервера (run ID)

Во-первых, давайте объясним приведенные выше существительные:

Смещение копии: обе стороны, выполняющие копирование,Поддерживать отдельносмещение копии

• Мастер добавляет N к своему смещению репликации каждый раз, когда он распространяет N байтов.
• Каждый раз, когда ведомое устройство получает N байт от ведущего, оно добавляет N к своему смещению репликации.

пройти черезСравните смещение репликации master-slave, легко узнать, находятся ли данные главного и подчиненного серверов в согласованном состоянии!

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

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

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

Итак, процесс примерно такой:

2.1.3 Распространение команд

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

Во время фазы распространения команд подчиненный сервер будет отправлять команды на сервер с частотой один раз в секунду по умолчанию.REPLCONF ACK <replication_offset>где replication_offset — текущее смещение репликации от сервера

Отправка этой команды имеет три основные функции:

• Определить состояние сети главного и подчиненных серверов
• Помогает реализовать опцию min-slaves
• Обнаружение потери команды

5. Наконец

После долгого рисования картины она, наконец, готова.

Закинул вопрос: если слейв сервер зависнет, не беда, у нас вообще несколько слейв серверов, а остальные запросы можно передать на не зависший слейв сервер для продолжения обработки. Что делать, если главный сервер выйдет из строя? Поскольку наши запросы на запись обрабатываются главным сервером, а главный сервер только один, он не может обрабатывать запросы на запись?

Проблема будет решена в следующей статье~~

Использованная литература:

• «Проектирование и реализация Redis»
• "Редис бой"

Если вы думаете, что я написал хорошо, проверьте:

• сохраняются воригинальныйТехнический общедоступный номер: Java3y.
• статьиНавигация по каталогу(Изысканная карта мозга + огромные видеоресурсы):GitHub.com/Zhongf UC очень…