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

Конфигурация репликации master-slave и принцип реализации Redis будут представлены ниже, а также будут представлены решения Redis для обеспечения высокой доступности: Sentinel, кластер разделов (Cluster)

Что такое master-slave репликация

мы можем пройтиslaveof <host> <port>командой или настроивslaveofВозможность заставить текущий сервер (ведомый) реплицировать содержимое указанного сервера (главного), реплицированный сервер называется главным сервером (мастер), а тот, который реплицирует главный сервер, является подчиненным сервером (ведомым).

Мастер главного сервера может выполнять операции чтения и записи.Когда данные главного сервера изменяются, мастер выдает поток команд для обновления подчиненного сервера, в то время как подчиненный сервер обычно доступен только для чтения (доступ к нему можно получить черезslave-read-onlyуказано), в режиме репликации ведущий-подчиненный, даже если главный не работает, подчиненный не может стать главным сервером для операций записи

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

Преимущества репликации master-slave:

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

Конфигурация репликации master-slave

Относительно просто использовать и настраивать репликацию master-slave, которая задается в файле конфигурации подчиненного сервера.slaveofвариант или использоватьslaveof <masterip> <masterport>Заказ

Здесь я использую 3 виртуальные машины для его сборки IP основного сервера192.168.249.20, IP-адреса двух подчиненных серверов192.168.249.21и192.168.249.21, оба номера порта6379, конкретная конфигурация выглядит следующим образом

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

# 设置为后台运行
daemonize yes
# 保存pid的文件，如果是在一台机器搭建主从，需要区分一下
pidfile /var/run/redis_6379.pid
# 绑定的主机地址，这里注释掉，开放ip连接
#bind 127.0.0.1
# 指定日志文件
logfile "6379.log"

Добавить конфигурацию с сервераslaveof <masterport> <masterport>опция, используемая в версии 5.0replicaofвместоslaveof(GitHub.com/Антиэнтузиазм/Горячие…),slaveofВы можете продолжать использовать его, но рекомендуется использоватьreplicaof. Если вы используете командную строку для копирования, она будет недействительна после перезапуска

# replicaof <masterip> <masterport>
replicaof 192.168.249.20 6379

Настроеноredis.confПосле этого запускаем 3 сервера отдельно, и пользователь может командоватьinfo replicationПросмотр информации о репликации

192.168.249.20:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.249.22,port=6379,state=online,offset=700,lag=0
slave1:ip=192.168.249.21,port=6379,state=online,offset=700,lag=0
master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:700
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:700

192.168.249.21:6379> info replication
# Replication
role:slave
master_host:192.168.249.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:854
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:854
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:57
repl_backlog_histlen:798

192.168.249.22:6379> info replication
# Replication
role:slave
master_host:192.168.249.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:854
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:b80a4720c0001efb62940f5ad6abaf9cdaf7a813
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:854
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:854

Затем мы можем записать данные на главный сервер, а затем прочитать данные на других подчиненных серверах.

192.168.249.20:6379> set test 'Hello World'
OK

192.168.249.21:6379> get test
"Hello World"

192.168.249.22:6379> get test
"Hello World"

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

192.168.249.21:6379> set test2 hello
(error) READONLY You can't write against a read only replica.

Если нам нужен слейв для проверки репликации мастера, его можно настроить в мастереrequirepass <password>опция установить пароль

Затем вам нужно использовать пароль на подчиненном сервере, вы можете использовать командуconfig set masterauth <password>или установить в файле конфигурацииmasterauth <password>

Принцип реализации master-slave репликации

Настройка репликации master-slave относительно проста, давайте разберемся с принципом реализации репликации master-slave.

Процесс репликации master-slave в Redis можно условно разделить на три этапа:установить соединение,синхронизация данных,распространение команды

установить соединение

Этот этап в основном отправляется с сервераslaveofПосле команды процесс установки соединения с основным сервером и подготовки к синхронизации данных.

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

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

3) Аутентификация. Если главный сервер установленrequirepassвариант, то подчиненный сервер должен быть настроенmasterauthвариант и убедитесь, что пароль тот же, чтобы пройти проверку

4) После завершения аутентификации подчиненный сервер отправит свой собственный порт прослушивания, а главный сервер сохранит его.

192.168.249.20:6379> info replication
...
slave0:ip=192.168.249.22,port=6379,state=online,offset=700,lag=0
slave1:ip=192.168.249.21,port=6379,state=online,offset=700,lag=0
...

синхронизация данных

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

Синхронизация Redis master-slave делится на:полная ресинхронизацияичастичная ресинхронизация

полная повторная синхронизация

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

Вот шаги для полной повторной синхронизации

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

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

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

runid(идентификатор репликации), идентификатор основного сервера, при запуске экземпляра Redis случайным образом генерируется уникальная строка длиной 40 для идентификации текущего узла.
offset, смещение копии. Ведущий и подчиненный каждый поддерживают смещение репликации, которое записывает количество переданных байтов. Когда главный узел отправляет N байтов данных ведомому узлу, смещение ведущего узла увеличивается на N, а когда ведомый узел получает N байтов данных от ведущего узла, смещение ведомого узла увеличивается на N
replication backlog buffer, скопируйте буфер невыполненной работы. представляет собой очередь FIFO фиксированной длины, размер которой определяется параметрами конфигурацииrepl-backlog-sizeУточните, размер по умолчанию 1 МБ. Следует отметить, что этот буфер поддерживается ведущим устройством и существует только один, все подчиненные устройства совместно используют этот буфер, и его роль заключается в резервном копировании данных, недавно отправленных главной библиотекой в подчиненную библиотеку.

Когда ведомое устройство подключается к ведущему, оно выполняетPSYNC <runid> <offset>отправить запись старого мастераrunid(ID репликации) и смещениеoffset, так что мастер может отправить только инкрементную часть, отсутствующую у ведомого. Но если в буфере невыполненной репликации ведущего недостаточно записей команд или ведомое устройство проходитrunid(идентификатор репликации) неверный, будет выполнятьсяполная повторная синхронизация, то есть слейв получит полную копию набора данных

Блок-схема команды PSYNC для выполнения полной и частичной повторной синхронизации

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

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

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

REPLCONF ACK <replication_offset>

вreplication_offsetсмещение репликации текущего ведомого сервера.Эта команда имеет три эффекта

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

Безопасность репликации при отключении сохраняемости

По поводу безопасности репликации при отключенном сохранении вот описание на официальном сайте.Woohoo. Redis. может комментировать только /topics/…

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

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

Мы устанавливаем узел A в качестве главного и отключаем его настройки сохраняемости, а узлы B и C реплицируют данные с узла A.
Нода А дает сбой, но у него есть какая-то система автоматического перезапуска, чтобы перезапустить процесс. Но так как постоянство отключено, набор данных становится пустым после перезапуска узла.
Узел B и узел C копируют данные с узла A, но набор данных узла A пуст, поэтому в результате копирования они уничтожают свои предыдущие копии данных.

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

Безопасность данных всегда важна, поэтому, если мастер использует репликацию и не настроено сохранение, процесс автоматического перезапуска следует отключить.

Ссылка: «Проектирование и реализация Redis»,redis replication