Следующие заметки и эксперименты взяты из видеоурока Shishan China, я следил за экспериментом и разбирал записи в классе.

Мастер-ведомая архитектура Redis

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

Узким местом, которое Redis не может поддерживать высокий параллелизм, является то, чтоавтономныйНевозможно для Redis с одной машиной сказать, что количество запросов в секунду превышает 100 000+, если только производительность вашей машины не особенно высока, а обслуживание выполняется хорошо. И ваша общая операция не может быть слишком сложной.

Следовательно, разделение чтения-записи обычно используется для поддержки высокого параллелизма. Количество запросов на запись относительно мало, а большое количество запросов прочитано, поэтому основная архитектура Redis - лучший выбор. Master-Slave Architector -> Разделение чтения-записи -> Горизонтальное расширение поддерживает высокую последовательность чтения, главный узел используется для записи, а подчиненный узел используется для чтения.

PS: В версии 5.0.4, которую я использую, термин «раб» был заменен на «реплика», гм~ Значение этого слова действительно немного уродливое. Все равно официалы поменяли, вот и поменял все.

Ссылки по теме:Changing Redis master-slave replication terms with something else

Основной механизм репликации redis (репликация master-slave)

Redis асинхронно реплицирует данные главного узла на узел-реплику, но, начиная с версии Redis 2.8, узел-реплика будет периодически подтверждать объем данных, которые он реплицирует каждый раз.
Главный узел может быть настроен с несколькими узлами-репликами.
Узел реплики также может подключаться к другим узлам реплики.
Когда узел-реплика реплицируется, он не будет блокировать нормальную работу главного узла.
Когда узел реплики выполняет репликацию, он не будет блокировать свои собственные операции запросов, он будет использовать старый набор данных для предоставления услуг, но когда репликация будет завершена, ему необходимо удалить старый набор данных и загрузить новый набор данных. Внешнее обслуживание приостановлено
Узел реплики в основном используется для горизонтального расширения и разделения чтения и записи.Расширенный узел реплики может повысить пропускную способность чтения.

Основной принцип репликации master-slave в redis

При запуске узла реплики он отправляетPSYNCкоманду главному узлу.

При использовании узла репликиPSYNCИсходное соединение с главным узлом, он будет вызвать полную ресинхронизацию полной громкости. В этот раз мастер начинает фоновую нить, RDB начал генерировать файл Snapshot, а также клиентский клиент все новая команда записи, полученная из кэша в памяти. После завершения генерации файла RDB Master RDB будет отправлена на эту реплику, Реплика сначала запишит на локальный диск, а затем загружается с локального диска в память, затем отправляет Master будет в памяти Cache Cash Command к реплике, реплика также может синхронизировать данные. Реплика узла Если теперь существует главный узел после сбоя сети, отключена, он автоматически снова подключается, подключен к главному узлу, скопированной частью отсутствующих данных реплики.

Что такое команда PSYNC?

Введение и подробное объяснение PSYNC

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

Формат PSYNC:

PSYNC runid offset

runid

Каждый сервер Redis будет иметь идентификатор, который идентифицирует себя. Идентификатор, отправленный в PSYNC, относится к идентификатору ранее подключенного Мастера.Если этот идентификатор не сохранен, Команда PSYNC будет отправлена Мастеру в виде «PSYNC ? -1», что указывает на то, что требуется полная копия.

смещение (копия смещения)

И Мастер, и Реплика в мастере, каждая из которых будет поддерживать смещение. Мастер успешно отправляет n байтов команд, добавьте смещение мастера плюс N, Реплика также добавляет N байт офиса после получения n байтовой команды. Мастер и реплика. Если статус непротиворечив, его OFFSET также должен быть непротиворечивым.

Полный процесс копирования

После того, как мастер главного узла получит полную команду репликации, выполните bgsave для локального создания файла моментального снимка rdb и используйте буфер (называемый буфером репликации) для записи всех команд записи, выполняемых с этого момента. В файле конфигурации Redis есть параметр: client-output-buffer-limit replica 256MB 64MB 60

Если буфер памяти потребляет более 64 МБ в течение более 60 секунд в течение периода копирования или более 256 МБ за один раз, копирование останавливается и происходит сбой копирования. Последние два параметра используются вместе, если: потребляет более 64 МБ Он длился 59 секунд, но не превышает 64 МБ за 60 секунд, поэтому сохраняйте соединение и продолжайте копирование.

Главный узел отправляет файл моментального снимка rdb на узел-реплику.Если время репликации rdb превышает 60 секунд (параметр файла конфигурации Redis: repl-timeout), узел-реплика будет считать, что репликация не удалась. Вы можете настроить этот параметр соответствующим образом (для машины с гигабитной сетевой картой обычно 100 МБ в секунду, файлы 6G передаются, и, вероятно, превысит 60 с)
Когда главный узел генерирует rdb, он кэширует все новые команды записи в памяти.После того, как узел-реплика сохранит rdb, он скопирует новые команды записи на узел-реплику; Подчиненный узел сначала очищает свои старые данные, а затем загружает полученный файл RDB.
Главный узел отправляет все команды записи в вышеупомянутом буфере репликации подчиненному узлу, и подчиненный узел выполняет эти команды записи.Если подчиненный узел включает AOF, он инициирует выполнение bgrewriteaof, тем самым обеспечивая обновление файла AOF. к последнему состоянию главного узла.

Процесс частичной репликации (добавочная репликация)

Если сетевое соединение мастер-реплика разорвется во время процесса полной репликации, добавочная репликация будет запущена, когда реплика повторно подключится к мастеру.
Мастер напрямую получает некоторые потерянные данные из собственного невыполненной работы и отправляет их на узел-реплику.Задержка по умолчанию составляет 1 МБ.
Мастер получает данные из бэклога в соответствии со смещением в psync, отправленном репликой.

Например, если смещение ведущего устройства равно 1000, а смещение подчиненного устройства равно 500, то частичная репликация потребует передачи данных по смещениям 501–1000 подчиненным устройствам.

Полный процесс репликации

Когда узел-реплика запускается, он локально сохраняет информацию о главном узле, включая хост и ip главного узла, но процесс репликации не запускается.

Внутри узла-реплики есть запланированная задача, которая каждую секунду проверяет, есть ли новый главный узел для подключения и репликации, и, если он найден, устанавливает сетевое соединение через сокет с главным узлом; Затем узел-реплика отправляет команду ping главному узлу. Если мастер устанавливает requirepass (то есть пароль для входа в redis), Затем узел-реплика должен отправить пароль masterauth для аутентификации, главный узел впервые выполняет полную репликацию и отправляет все данные узлу-реплике; После этого главный узел продолжает асинхронно реплицировать команду записи на узел-реплику.

Шаг 1: Сервер подчиненного узла поддерживает два поля, поля masterhost и masterport, которые используются для хранения информации об IP-адресе и порте главного узла.
Шаг 2: Установите сокетное соединение, то есть ведомый узел вызывает функцию синхронизации репликации replicationCron() один раз в секунду.Если он обнаружит, что есть главный узел, к которому можно подключиться, он создаст сокетное соединение в соответствии с ip и порт главного узла.
Шаг 3: Аутентификация, если на подчиненном узле установлена опция masterauth, подчиненный узел должен пройти аутентификацию на главном узле; если эта опция не установлена, аутентификация не требуется; Аутентификация подчиненного узла осуществляется путем отправки на главный узел команды auth.Параметром команды auth является значение masterauth в конфигурационном файле, если главный узел устанавливает статус пароля, Если он согласуется со статусом masterauth ведомого узла (согласованный означает, что оба существуют, а пароли одинаковы, или ни один из них не существует), аутентификация проходит, и процесс репликации продолжается; если он несовместим, ведомый узел отключается. подключение к сокету и повторное подключение.
Шаг 4: Синхронизация данных — это полная репликация или добавочная репликация, и команды записи, которые продолжают существовать на этапе репликации, будут храниться в памяти главного узла и позже будут отправлены на узел реплики асинхронно.

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

Репликация master-slave с возобновлением работы с точки останова

Начиная с redis 2.8 поддерживается возобновление репликации master-slave по точке останова.Если сетевое соединение обрывается в процессе репликации master-slave, вы можете продолжить копирование с места, где была сделана последняя копия, вместо копирования копии из царапать.

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

Но если соответствующее смещение не будет найдено, то будет выполнена ресинхронизация (полная копия)

бездисковая копия

Мастер создает RDB непосредственно в памяти, а затем отправляет его в реплику и не размещает локально на диске. Просто включите repl-diskless-sync yes в файле конфигурации.

repl-diskless-sync yes

# 等待 5s 后再开始复制，因为要等更多 replica 重新连接过来
repl-diskless-sync-delay 5

Обработка ключей с истекшим сроком действия

Реплика не истечет срок действия ключа, она просто ждет, пока мастер не истечет срок действия ключа. Если у мастера истекает срок действия ключа или он удаляет ключ через LRU, он имитирует команду del и отправляет ее реплике.

heartbeat

Главный и подчиненный узлы будут отправлять друг другу информацию о пульсе.

Мастер по умолчанию отправляет контрольные сообщения каждые 10 секунд, а узел-реплика отправляет контрольные сообщения каждые 1 секунду.

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

Если используется архитектура master-slave, рекомендуется включить постоянство главного узла! Как реализовать постоянство Redis

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

Кроме того, необходимо выполнить различные решения для резервного копирования Мастера. В случае потери всех локальных файлов из резервной копии выбирается RDB для восстановления Master, чтобы можно было гарантировать ее запуск. Даже с механизмом высокой доступности последующих объяснений узел-реплика может автоматически взять на себя главный узел, но, возможно, Sentinal не обнаружил сбой главного узла, главный узел автоматически перезапускается. Все еще возможно заставить все данные узла реплики очистить ошибку.

Реализовать архитектуру репликации master-slave в Redis (один главный и один подчиненный).

node	hostname	IP	port
master node	eshop-cache01	192.168.0.30	6379
replica node	eshop-cache02	192.168.0.31	6379

Строительство окружающей среды

В дополнение к параметрам, настроенным при установке redis, на ведомом узле также необходимо дополнительно настроить следующее.

Настройте файл конфигурации главного узла (eshop-cache01)

Изменить в файле конфигурацииbind 127.0.0.1дляbind 192.168.0.30собственный IP-адрес

Или настроен на привязку 0.0.0.0 если ip адрес настроен сам, то необходимо при использовании клиентской части redis, с помощью клиента redis-cli -h 192.168.0.30 войти в

Настроить пароль аутентификацииrequirepass redis-pass, это пароль для входа в Redis

Настройте файл конфигурации подчиненного узла (eshop-cache02)

Изменить в файле конфигурацииbind 127.0.0.1дляbind 192.168.0.31собственный IP-адрес
настроитьreplicaofдляreplicaof eshop-cache01 6379eshop-cache01 Я на главном узле/etc/hostsНастроен для сопоставления ip локальной машины

replicaof заполните ip и номер порта мастер-узла

Включить аутентификацию безопасностиmasterauth redis-passЗаполните пароль для входа в мастер-ноду, который необходимо настроить в файле конфигурации мастер-ноды.
Принудительное разделение чтения и записиreplica-read-only yesЭто включено по умолчанию

Вы можете свободно выбирать, следует ли включать постоянство AOF.

Тестовая репликация master-slave (разделение чтения-записи)

Запустите экземпляр redis главного узла и подчиненного узла последовательно, войдите в клиент главного узла,set k1 v1Затем узел видит, были ли прочитаны данные, которые представляют данные, прочитанные успешно.

info replicationКоманда может проверить, является ли его роль главным узлом или подчиненным узлом.

Расширенное чтение

Архитектура Redis master-slave
Углубленное изучение Redis (3): репликация master-slave