Можно сказать, что архитектура «ведущий-ведомый» является необходимой архитектурой для Интернета. Во-первых, она обеспечивает высокую доступность сервисов, а во-вторых, обеспечивает разделение чтения и записи. Возможно, вы знакомы с архитектурой «ведущий-ведомый» в наша часто используемая база данных MySQL.Для нашего Redis Неудивительно, что база данных Redis также имеет различные архитектуры master-slave.В архитектуре master-slave задействована синхронизация данных между главным узлом и подчиненными узлами.Этот процесс синхронизации данных называется репликацией в Redis, который описан в этой статьеВ этой статье мы подробно рассказываем о технологии репликации и архитектуре master-slave в Redis.Эта статья в основном включает следующее содержание:

Создание среды архитектуры «ведущий-ведомый»
- Как построить архитектуру master-slave
- Отключение мастер-рабской архитектуры
Принцип технологии репликации
- процесс синхронизации данных
- Обнаружение сердцебиения
Топология ведущий-ведомый
- Один хозяин и один раб
- Один хозяин, много рабов
- Дерево

Главное здание из окружения

Экземпляры Redis по умолчанию являются главными узлами, поэтому нам нужно изменить некоторые конфигурации для построения архитектуры master-slave.Архитектура master-slave в Redis относительно проста.Redis предоставляет три способа построения архитектуры master-slave.Мы представим ее , Перед введением мы должны сначала понять характеристики архитектуры master-slave: в архитектуре master-slave есть главный узел (master) и по крайней мере один подчиненный узел (slave), а репликация данных является односторонней, только с главного узла реплицируется на подчиненный узел, а не с подчиненного узла на главный узел.

Как построить архитектуру master-slave

Есть три способа установить архитектуру master-slave:

Добавьте команду slaveof {masterHost} {masterPort} в файл конфигурации Redis.conf, чтобы она вступила в силу при запуске экземпляра Redis.
Добавьте параметр --slaveof {masterHost} {masterPort} после команды запуска redis-server.
Используйте команду непосредственно в интерактивном окне redis-cli: slaveof {masterHost} {masterPort}

Вышеупомянутые три способа могут быть созданы из мастера REDIS, и мы демонстрируем первый способ, а другие два способа предпринимаются попытки, поскольку это демонстрация, поэтому локально запускаются два экземпляра Redis локально, а Redis не запускается. на нескольких машинах. Экземпляр, мы готовим пример основного узла порта 6379, подготавливаем порт 6480 из экземпляра узла, файл конфигурации экземпляра Redis с портом 6480 называется6480.confИ добавьте в него оператор slaveof и добавьте следующий оператор в конец файла конфигурации

slaveof 127.0.0.1 6379

Запустите два экземпляра Redis соответственно. После запуска они автоматически установят отношения ведущий-ведомый. Мы подробно поговорим о принципе, лежащем в основе этого, позже. Давайте сначала проверим, успешно ли построена наша архитектура ведущий-ведомый. Начнем с 6379 master A к узлу добавляется новый фрагмент данных:

Затем получите данные о ведомом узле 6480:

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

Видно, что роль экземпляра порта 6379 является мастером, есть подключаемый экземпляр и есть другая рабочая информация, давайте посмотрим на информацию об экземпляре Redis порта 6480.

Видно, что между двумя узлами записывается информация об объекте, которая будет использоваться при репликации данных. Здесь нужно пояснить одно,По умолчанию узел Slave доступен только для чтения, запись не поддерживается, и не рекомендуется включать запись., мы можем убедиться, что часть данных записана на экземпляре 6480

127.0.0.1:6480> set x 3
(error) READONLY You can't write against a read only replica.
127.0.0.1:6480>

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

Отключение архитектуры master-slave

Отключение архитектуры master-slave также является командой slaveof.Выполните команду slaveof no one на ведомом узле, чтобы отключить следующую связь с ведущим узлом.Мы выполняем команду slaveof no one на узле 6480.

127.0.0.1:6480> slaveof no one
OK
127.0.0.1:6480> info replication
# Replication
role:master
connected_slaves:0
master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0
master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27
master_repl_offset:4367
second_repl_offset:4368
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:4367
127.0.0.1:6480>

После выполнения команды slaveof no one роль ноды 6480 сразу восстанавливается до master, посмотрим когда он подключится к инстансу 6379, добавляем к ноде 6379 ключ-значение

127.0.0.1:6379> set y 3
OK

получить y на узле 6480

127.0.0.1:6480> get y
(nil)
127.0.0.1:6480>

Невозможно получить y на узле 6480, так как узел 6480 был отключен от узла 6379, и нет отношения ведущий-ведомый Команда slaveof может не только разорвать соединение, но и переключить главный сервер. команда какslaveof {newMasterIp} {newMasterPort}, мы делаем 6379 подчиненным узлом 6480 и выполняем его на узле 6379slaveof 127.0.0.1 6480Командование, давайте посмотрим на репликацию информации 6379

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6480
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:4367
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:4367
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:4368
repl_backlog_histlen:0
127.0.0.1:6379>

Роль ноды 6379 уже ведомая, а мастер нода 6480, можем еще раз посмотреть репликацию инфо ноды 6480

127.0.0.1:6480> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1
master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea
master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0
master_repl_offset:4479
second_repl_offset:4368
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:4479
127.0.0.1:6480>

На узле 6480 ведомых узлов 6379. Видно, что команда slaveof помогла нам завершить переключение главного сервера.

Принцип технологии репликации

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

Принцип репликации данных

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

За командой slaveof главный-подчиненный сервер прошел примерно семь шагов. Шаг проверки разрешения не требуется. Чтобы лучше понять эти шаги, давайте возьмем экземпляр redis, который мы создали выше, в качестве примера, чтобы рассказать о каждом шаге в деталь.

1. Сохраните информацию о главном узле.

Клиент на 6480 отправляет на сервер узла 6480slaveof 127.0.0.1 6379команду, сразу получаем ОК

127.0.0.1:6480> slaveof 127.0.0.1 6379
OK
127.0.0.1:6480>

В это время работа репликации данных не начинается, и работа репликации данных начинается после возврата OK.В это время подчиненный узел 6480 сохраняет заданный IP-адрес главного сервера 127.0.0.1 и порт 6379 на сервере. состояние Внутри атрибута masterhost и атрибута masterport

2. Установите сокетное соединение

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

3. Отправьте команду ping

После того, как подчиненный сервер успешно подключен к главному серверу, первое, что нужно сделать, это отправить команду ping на главный сервер.Отправка команды ping имеет следующие цели:

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

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

4. Аутентификация

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

Аутентифицироваться, если параметр masterauth установлен с сервера
Если для ведомого устройства не установлен параметр masterauth, аутентификация не выполняется.

Когда требуется аутентификация, подчиненный сервер отправляет команду авторизации на главный сервер. Параметр команды представляет собой значение параметра masterauth подчиненного сервера. Например, если параметр masterauth установлен на 123456 в конфигурации подчиненного сервер, затем ведомый Сервер отправит на главный сервер команду auth 123456. Процесс аутентификации не является гладким, и могут возникнуть следующие ситуации:

Пароль, отправленный подчиненным сервером через команду auth, совпадает со значением параметра requirepass главного сервера, последующая операция будет продолжена.Если пароли несовместимы, главная служба вернет ошибку неверного пароля.
Если главный сервер не устанавливает параметр requirepass, то главный сервер вернет ошибку «пароль не установлен».

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

5. Отправьте информацию о порте

После прохождения аутентификации подчиненный сервер выполнит команду прослушивания REPLCONF и отправит номер порта прослушивания подчиненного сервера на главный сервер.Например, в нашем примере порт прослушивания подчиненного сервера — 6480, затем подчиненный сервер отправит REPLCONF слушая команду 6480 на главном сервере., после того, как главный сервер получит эту команду, он запишет номер порта в атрибуте slave_listening_port состояния клиента, соответствующем подчиненному серверу, что является значением порта, которое мы видим в репликации информации главный сервер.

6. Репликация данных

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

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

Причина, по которой Redis может поддерживать полную и частичную репликацию, заключается главным образом в оптимизации команды синхронизации.После версии Redis 2.8 используется новая команда psync.Формат команды: psync {runId} {offset}.значение:

runId: идентификатор работающего главного узла.
offset: смещение данных, скопированных в данный момент с узла

Возможно, вы не знакомы с указанными выше runid и offset. Это не имеет значения. Давайте рассмотрим следующие три понятия:

1. Скопируйте смещение

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

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

2. Скопируйте буфер невыполненной работы

Буфер невыполненной репликации — это очередь фиксированной длины, хранящаяся на ведущем узле. Размер по умолчанию — 1 МБ. Он создается, когда к ведущему узлу подключен подчиненный узел. В это время, когда главный узел (мастер) отвечает на запись команда, она не только отправит команду на ведомый узел, но и запишет буфер невыполненной репликации, как показано на следующем рисунке:

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

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

3, идентификатор запуска сервера

После запуска каждого узла Redis в качестве рабочего идентификатора динамически назначается 40-значная шестнадцатеричная строка. Основная функция рабочего идентификатора — однозначно идентифицировать узел Redis. Мы можем использоватьinfo serverкоманда для просмотра

127.0.0.1:6379> info server
# Server
redis_version:5.0.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:2ef1d58592147923
redis_mode:standalone
os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:25214
run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1
tcp_port:6379
uptime_in_seconds:14382
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:14554933
executable:/usr/local/redis-5.0.5/src/./redis-server
config_file:/usr/local/redis-5.0.5/redis.conf
127.0.0.1:6379>

Eстьrun_idПоле представляет собой идентификатор работающего сервера.

После понимания этих концепций давайте взглянем на процесс выполнения команды psync.На следующем рисунке показан процесс выполнения команды psync:

Логика команды psync относительно проста, и весь процесс разбит на два этапа:

1. Ведомый узел отправляет команду psync главному узлу. Параметр runId — это текущий идентификатор главного узла, сохраненный текущим подчиненным узлом, а параметр offset — это смещение репликации, сохраненное текущим подчиненным узлом. при первом участии в репликации значение по умолчанию равно -1.

2. После того, как главный узел получит команду psync, он отправит подчиненному серверу один из следующих трех ответов:

Ответить +FULLRESYNC {runId} {смещение}: Указывает, что главный сервер выполнит полную операцию репликации с подчиненным сервером, где runid — это текущий идентификатор главного сервера, подчиненный сервер сохранит этот идентификатор и будет использовать его при отправке команды psync в следующий раз, а смещение — это текущее смещение репликации главного сервера. Подчиненный сервер будет использовать это значение как собственное смещение инициализации.
Ответить на +ПРОДОЛЖИТЬ: Тогда это означает, что главный сервер и подчиненный сервер будут выполнять операцию частичного копирования, а подчиненному серверу нужно будет только дождаться, пока главный сервер отправит недостающую часть данных.
Ответить + ERR.: Тогда это означает, что версия мастер-сервера ниже, чем redis 2.8, он не может распознать команду psync, подчиненный сервер отправит команду синхронизации на мастер-сервер и выполнит полную репликацию с мастер-сервером.

7. Команды постоянно копируются

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

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

Обнаружение сердцебиения

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

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

По умолчанию главный узел отправляет команду ping подчиненному узлу каждые 10 секунд, чтобы оценить живучесть и состояние подключения подчиненного узла. Частоту отправки можно контролировать, изменив параметр repl-ping-replica-period в конфигурационном файле redis.conf.
Ведомый узел отправляет команду replconf ack {offset} в основном потоке каждую 1 секунду, чтобы сообщить о своем текущем смещении репликации главному узлу.В дополнение к обнаружению сети узла ведущий-ведомый эта команда также отправляет смещение репликации главному узлу. узел. Обеспечьте согласованность данных между ведущим и ведомым

Главный узел оценивает время ожидания подчиненного узла в соответствии с командой replconf, что отражается в информации о задержке в статистике репликации информации.Выполняем команду репликации информации на главном сервере:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0
master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:25774
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:25774
127.0.0.1:6379>

Видно, что в конце значения поля slave0 есть задержка. Задержка представляет собой количество секунд последней задержки связи с подчиненным узлом. Нормальная задержка должна быть между 0 и 1. Если оно превышает значение, настроенное параметром repl-timeout (по умолчанию 60 секунд), определяется, что подчиненный узел находится в автономном режиме, и соединение с клиентом репликации разрывается. Если подчиненный узел восстанавливается, обнаружение контрольных импульсов будет продолжено.

Топология ведущий-ведомый

Топология Redis «ведущий-ведомый» может поддерживать одноуровневые или многоуровневые отношения репликации.В соответствии со сложностью топологии ее можно разделить на следующие три типа: один главный и один подчиненный, один главный и несколько подчиненных и древовидный. как архитектура «хозяин-раб».

Структура ведущий-ведомый

Структура один мастер-один ведомый — это простейшая топология репликации.То, что мы построили ранее, — это архитектура один мастер-один ведомый.Архитектура показана на рисунке:

Архитектура ведущий-ведомый используется для обеспечения поддержки аварийного переключения для подчиненного узла, когда главный узел не работает.Когда команда записи приложения имеет большое количество параллелизма и должна быть сохранена, AOF может быть включен только на подчиненном узле, который не только обеспечивает безопасность данных, но также позволяет избежать влияния на производительность сохранения на главном узле. Но здесь есть ямка, которая требует вашего внимания, то есть, когда мастер-нода отключает функцию сохранения, если мастер-нода уходит в автономный режим, необходимо избегать операции автоматического перезапуска. Поскольку главный узел ранее не включал функцию сохранения, а набор данных пуст после автоматического перезапуска, если подчиненный узел продолжает копировать главный узел, данные подчиненного узла также будут очищены, что теряет смысл сохраняемости. . Безопасный способ — выполнить slaveof no one на подчиненном узле, чтобы отключить отношения репликации с главным узлом, а затем перезапустить главный узел, чтобы избежать этой проблемы.

Архитектура «один главный — несколько подчиненных»

Архитектура с одним ведущим и несколькими ведомыми устройствами также известна как топология «звезда».Архитектура с одним ведущим и несколькими ведомыми устройствами показана на следующем рисунке:

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

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

Древовидная архитектура master-slave также называется древовидной архитектурой топологии.Древовидная архитектура master-slave показана на следующем рисунке:

Древовидная архитектура master-slave позволяет подчиненным узлам не только реплицировать данные главного узла, но и продолжать репликацию на нижние уровни в качестве главного узла других подчиненных узлов. Чтобы устранить недостатки архитектуры «один главный — несколько подчиненных», путем введения промежуточного уровня репликации можно эффективно уменьшить нагрузку на главный узел и объем данных, которые необходимо передать на подчиненные узлы. Как показано на диаграмме архитектуры, после записи данных на узел A они будут синхронизированы с узлами B и C, а узел B затем синхронизирует данные с узлами D и E. Данные реплицируются слой за слоем. Когда главному узлу необходимо смонтировать несколько подчиненных узлов, чтобы избежать помех производительности главного узла, можно использовать древовидную структуру ведущий-ведомый, чтобы уменьшить нагрузку на главный узел.

наконец

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

Добро пожаловать, чтобы отсканировать код и подписаться на общедоступную учетную запись WeChat: «Технический блог Pingtou Ge», Pingtou Ge будет учиться и добиваться прогресса вместе.