1. Введение
Высокая доступность имеет два значения: во-первых, стараться не терять данные, а во-вторых, предоставлять сервисы в максимально возможном объеме. AOF и RDB гарантируют, что персистентность данных не будет потеряна в максимально возможной степени ([принцип aof и rdb можно увидеть в основной части 2](Redis Core (2) — Сохранение данных — Самородки (juejin.cn))) А репликация master-slave заключается в увеличении копии, сохранении копии данных в нескольких экземплярах. Sentinel — это когда узел кластера выходит из строя, вы можете автоматически переносить сбой, продолжать предоставлять услуги.
2. Мастер-раб
В reids вы можете выполнить команду replicaof (slaveof до Redis 5.0), чтобы сформировать связь между главной библиотекой и подчиненной библиотекой, или настроить параметр replicaof в файле конфигурации, чтобы позволить одному серверу реплицировать другой сервер, а реплицированный сервер — это главный сервер (master), а сервер, который реплицирует главный, называется подчиненным
Отношения между хозяином и рабом:
- Основная служба может иметь несколько подчиненных серверов или не иметь подчиненной службы.Обычно служба Redis ничему не соответствует, и по умолчанию используется мастер.
- Подчиненный сервер может иметь только один главный
2.1 Главное от ассоциации
По умолчанию Redis Service Service Suparts - это мастер, настроить отношения Master-Slave можно включить информацию о конфигурации основного узла от основной копии, следующие три способа:
- Файл конфигурации: добавьте следующую конфигурацию в файл конфигурации подчиненного сервера.
replicaof <masterip> <masterport>
- Параметры запуска: добавьте следующие параметры после команды запуска redis-server: --replicaof masterip masterport
- Команда клиента: после подключения к Redis выполните команду: replicaof masterip masterport, после чего экземпляр Redis станет подчиненным узлом.
2.1.1 Демонстрация
- После подключения клиента выполните следующую команду:
- Просмотрите журнал хост-узла:
Видно, что когда главный узел связан с ведущим и ведомым, он выполнит команду BGSAVE, которая находится в (Redis Core (2) — Сохранение данных — Самородки (juejin.cn)) имеет подробное описание, и незнакомые друзья могут перемещаться для его просмотра.
2.2 Согласованность данных ведущий-ведомый
Так как отношения master-slave включают в себя несколько узлов, то между несколькими узлами неизбежно будет задействована проблема задержки синхронизации данных между узлами, то есть схема согласованности данных, тогда какова схема redis для согласованности данных? ? Что касается того, как должны синхронизироваться данные между несколькими узлами, как показано на рисунке выше, я примерно нарисовал решения по трем направлениям, если у вас есть другие решения, вы можете оставить сообщение в комментариях:
- Решение с сильной согласованностью: синхронизация данных между узлами полностью синхронизирована, и все узлы отвечают клиенту после записи данных. Это решение способствует надежности в компромиссе между высокой производительностью и высокой надежностью; хотя надежность данных гарантируется, это также влияет на производительность, особенно при наличии нескольких подчиненных узлов.
- Решение с сильной согласованностью: синхронизация данных между узлами полностью асинхронна. Это решение представляет собой компромисс между высокой производительностью и высокой надежностью, и оно ориентировано на высокую производительность. Производительность повышается, и надежность данных не может быть гарантирована. , легко потерять данные.
- Решение для конечной согласованности: мастер отправляет сообщения в асинхронную очередь (или буфер) и потребляет данные в очереди (буфере) через асинхронные потоки, чтобы синхронизировать данные между узлами с высокой производительностью и высокой надежностью. является компромиссом между собой. На самом деле, это также получено из базовой теории.BASE относится к базовой доступности, мягкому состоянию и согласованности в конечном итоге.
На самом деле, для большинства продуктов с открытым исходным кодом не существует конкретного решения для компромисса между высокой производительностью и высокой надежностью.Обычно право принятия решений предоставляется пользователю.Как и механизм подтверждения kafka, параметр равен 0. или 1. Или -1, пользователи решают, хотят ли они высокую пропускную способность сообщений или высокую надежность сообщений в соответствии со своими собственными бизнес-сценариями, но для нашего Redis он не обеспечивает такой гибкой конфигурации, он использует асинхронную репликацию по умолчанию, слабая согласованность лучшее решение, потому что оно преследует максимальную производительность.
2.3 Принцип синхронизации master-slave
В реализации репликации master-slave в Redis есть две разные версии реализации: команда sync, используемая до версии 2.8, и команда psync, используемая в версиях после 2.8 и 2.8. В этой статье будет представлена реализация этих двух команд соответственно.
Репликация master-slave в основном делится на две операции: синхронизацию данных и распространение команд.
- Синхронизация данных: в основном обновите состояние подчиненного сервера до состояния главного сервера.
- Распространение команд: в основном используется для возврата состояния главного и подчиненного серверов в одно и то же состояние, когда состояние главного сервера изменяется, что приводит к несогласованности данных главного и подчиненного.
Синхронизацию данных можно разделить на две ситуации:
- Первая синхронизация: синхронизация данных, когда ведомый узел подключается к ведущему в первый раз.
- Отключить повторное подключение: повторное подключение к мастеру после отключения от узла.
2.3.1 sync
2.3.1.1 Первая синхронизация
Первый процесс репликации главной библиотеки можно условно разделить на три фазы: 1) фаза установления соединения (т. е. фаза подготовки);
- Стадия установления соединения: основная функция этого этапа — установить соединение между ведущим и ведомым узлами для подготовки к полной синхронизации данных. Когда подчиненная библиотека устанавливает соединение с главной библиотекой, подчиненная библиотека выполняет команду slaveof и отправляет команду синхронизации, чтобы сообщить главной библиотеке о предстоящей синхронизации.После того, как главная библиотека подтвердит ответ, главная и подчиненная библиотеки начинают синхронизироваться. .
- Второй этап: мастер выполняет команду bgsave для генерации RDB-файла и отправляет файл в ведомую библиотеку, при этом главная библиотека открывает буфер для каждого ведомого для записи всех команд записи, полученных с момента генерации файл RDB, подчиненная библиотека получает файл RDB, затем сохраняет его на диск, очищает данные текущей базы данных, а затем загружает данные файла RDB в память
- Третий этап: после того, как ведомый узел загружает RDB, ведущий отправляет данные буфера ведомому узлу, ведомый получает и выполняет их, а ведомый узел синхронизируется с тем же состоянием, что и главный узел.
Из приведенного выше процесса нетрудно увидеть, что при синхронизации master-slave, если в это время параллелизм бизнеса высок, qps команды записи будет расти, и контейнер заставит подчиненный узел загрузить rdb. Емкость буфера слишком мала, что приводит к тому, что мастер в случае сбоя синхронизации выполняет повторную синхронизацию; легко сформировать бесконечный цикл операций повторной передачи bgsave и rdb.
2.3.1.2 Отключение и повторное подключение
Перед версией 2.8 команда синхронизации, используемая для синхронизации, не очень хорошо обрабатывала отключение и переподключение. Когда возникает разъединение мастер-раб, и снова возникает переподключение; шаги, которые будут выполнены, такие же, как первый процесс синхронизации мастера и Полное количество репликации, процесс такой же, как первая синхронизация, и здесь не будет описана.
2.3.2 psync
В версии 2.8 для первичной синхронизации Redis использует команды psync, а реализация Psync, в основном, оптимизирует мастер SYNC от отключения, а недостатки требуются для полной репликации; замена полного объема на инкрементную репликацию
Инкрементная репликация: используется для репликации после прерывания сети и т. д., на подчиненный узел отправляется только команда записи, выполняемая ведущим узлом во время прерывания, что более эффективно, чем полная репликация
2.3.2.1 Смещение копирования, буфер невыполненной работы копирования, идентификатор запущенной службы
Функция частичной повторной синхронизации состоит из следующих трех частей:
- Смещение репликации главного сервера и смещение репликации подчиненного сервера.
- Скопируйте главный буфер невыполненной работы (журнал репликации).
- Идентификатор запуска сервера (идентификатор запуска)
Непосредственно выше процесс распространения команды master-slave выглядит следующим образом: когда главный сервер выполняет распространение команды, он не только отправляет команду записи на все подчиненные серверы, но также сохраняет команду записи в буфере невыполненной репликации.
-
Смещение репликации для ведущего и смещение репликации для ведомого
- Каждый раз, когда главный сервер передает N байтов данных подчиненному серверу, значение его смещения репликации увеличивается на N
- Каждый раз, когда ведомая служба получает N байтов данных, значение смещения ее копии увеличивается на N.
-
Идентификатор запуска службы (runId), независимо от того, имеет ли главный сервер или подчиненный сервер собственный идентификатор запуска службы, идентификатор запуска создается автоматически при запуске сервера, например, 33b9b28ef80q2fdc9ab5e3fcbbbabff4dcdcedbg.
-
Копировать буфер невыполненной работы:
- Буфер для разблокировки репликации представляет собой в первую очередь, в первую очередь, поддерживающую основной сервис. Размер по умолчанию составляет 1 м. Когда очередь заполнена, элементы, которые первоначально введены в очередь, будут автоматически выпущены.
- Буфер невыполненной репликации в основном хранит два типа данных: смещение репликации (смещение) и байтовую команду, соответствующую смещению репликации; когда главный сервер выполняет распространение команды, он не только отправляет команду записи на подчиненный сервер, но и также Команда записи и соответствующее смещение записываются в очередь.
2.3.2.2 Принцип инкрементной синхронизации
Разобравшись с идентификатором сервера, смещением копирования и буфером невыполненной работы копирования, давайте посмотрим, как psync обеспечивает инкрементную синхронизацию, как показано на рисунке выше, а именно:
- Когда подчиненный сервер отключен и снова получена инструкция команды копирования, команда psync, отправленная в главную службу, будет содержать runId последнего мазера и смещение последней копии.
- Когда главный сервер получает команду psync, он проверяет, соответствует ли runId его собственному рабочему идентификатору. Если они совпадают, то проверяет, существуют ли данные команды после смещения в буфере невыполненной репликации. Если да, вернет результат инкрементной синхронизации, в противном случае возвращается полный результат синхронизации; когда выполняется инкрементная синхронизация, ведомому узлу нужно только синхронизировать команду для копирования буфера невыполненной работы, а ведущему узлу не нужно генерировать rdb файл для подчиненного узла для перезагрузки.
3. Sentinel.
Хотя архитектуру Master-Slave можно использовать для отделения чтения и записи, чтобы уменьшить давление считывания одномашина, когда мастер зависает, архитектуру Master-Plave не может автоматически выбрасывать новый мастер, и весь мастер-раб не может Дольше предоставьте письменные возможности. Следовательно, для высокодоступной модели системы архитектуры, мастер-раб достаточно далеко не достаточно; должен быть решение высокого доступности. После того, как главный сервер зависает, в пределах определенных условий, оригинальный ведомый сервер может быть выбран Как мастер, так что весь кластер Redis все еще можно использовать. Может предоставлять услуги чтения и записи внешнему миру.
3.1 Что такое часовой
Sentinel — это рабочий режим Redis, который фокусируется на отслеживании рабочего состояния экземпляров Redis и может осуществлять выбор главного узла и переключение между ведущими и подчиненными с помощью ряда механизмов при сбое главного узла, осуществлять аварийное переключение и обеспечивать работу всей системы Redis. Доступность; вкратце, Sentinel имеет следующие функции:
- Монитор: постоянно контролируйте, находятся ли ведущий и ведомый устройства в ожидаемом рабочем состоянии.
- Не в сети:
- объективно офлайн
- Субъективный офлайн
- отказоустойчивость
3.2 Сторожевая функция
3.2.1 Мониторинг
По умолчанию Sentinel отправляет команды PING всем экземплярам (мастер-серверам, подчиненным серверам, другим узлам службы Sentinel), которые создали с ним командную ссылку, с частотой один раз в секунду и оценивает, находится ли экземпляр в сети или нет, посредством PING. ответ на команду, возвращаемый экземпляром, или выжить
Ответ экземпляра на команду PING можно разделить на два случая:
- Действительный ответ: экземпляр возвращает один из трех ответов: +PONG, -LOADING и -MASTERDOWN.
- Неверный ответ: экземпляр возвращает ответ, отличный от + PONG, -Loading, -Masterdown, или нет ответа возвращается в течение указанного ограничения по времени
Время конфигурации для недействительных ответов: опция «Вниз-Миллисекунды» в файле конфигурации Sentinel указывает продолжительность времени, которое требуется SOSTINEL, чтобы определить, что экземпляр входит в субъективное оффлайн. Неверный ответ, Sentinel отметит экземпляр в качестве субъективного автономного состояния Отказ
3.2.2 Офлайн
3.2.2.1 Субъективный офлайн
Дозорный узел использует команду PING, чтобы определить, активен ли экземпляр, с которым установлена связь.Если ответ на команду PING недействителен, дозорный узел пометит экземпляр как субъективно отключенный.
Судить о том, жив ли соответствующий экземпляр или нет, просто полагаясь на субъективный автономный режим, крайне ошибочно; из введения в разделе мониторинга мы видим, что существует множество факторов, влияющих на то, является ли ответ на команду PING недействительным или действительным. ответ, такой как загрузка различных дозорных. Ситуация, сетевая ситуация, в которой расположен дозорный узел, и соответствующая конфигурация после миллисекунд.
Основываясь на субъективном автономном режиме, субъективность различных дозорных узлов слишком сильна.Для отслеживаемого экземпляра, если роль (запрос информационной команды) экземпляра является подчиненным, вы можете напрямую судить о том, жив ли экземпляр по субъективному автономному режиму.Если если роли экземпляра является ведущим, невозможно судить о том, жив экземпляр или нет, по субъективному автономному поведению одного дозорного узла.Об этом необходимо судить путем объединения результатов мониторинга большего количества дозорных, чтобы уменьшить скорость ошибочных суждений.
3.2.2.2 Объективная офлайн
Оценка того, находится ли мастер в автономном режиме, не может быть определена только одним дозорным; когда количество дозорных узлов, которые определяют субъективный автономный режим мастера, достигает кворума (настраивается), мастер может быть помечен как объективный в автономном режиме, что означает, что это объективный факт существования;
Кворум здесь является настраиваемым параметром, который определяется конфигурацией дозорного узла, ниже приведен файл конфигурации дозорного узла:
# sentinel monitor <master-name> <master-host> <master-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
Этот элемент конфигурации используется для информирования Sentinel о главном узле, который необходимо отслеживать:
- дозорный монитор: представляет мониторинг
- mymaster: представляет имя главного узла
- 127.0.0.1 и 6379 представляют имя и номер порта главного узла соответственно.
- 2: представляет кворум, представляя, что только два или более дозорных считают, что главный узел недоступен, основная настройка — это объективное автономное состояние.
Для разных дозорных, контролирующих один и тот же главный узел, их условия для оценки главного как объективно отключенного также могут быть разными: когда дозорный считает, что мастер объективно отключен, другие дозорные могут так не думать. Например, значение конфигурации кворума другого дозорного узла может быть равно 5.
более половинный механизм: при наличии N экземпляров дозорных, должно быть N/2 + 1 экземпляров, чтобы определить мастер как «субъективно отключенный», чтобы окончательно определить мастер как «объективный автономный».
3.2.3 Автоматическое переключение ведущий-ведомый
3.2.3.1 Дозор лидера выборов
Когда главный сервер объективно считается отключенным, каждый дозорный, отслеживающий отключенный от сети главный сервер, согласует, выберет ведущий дозорный, и ведущий дозорный выполнит операцию аварийного переключения на отключенном от сети главном сервере.
Прежде чем узнать о лидере выборов, запомните ключевое слово, настройте эпоху:
эпоха конфигурации: Эпоха конфигурации является счетчиком.Для каждого выбора дозорного значение эпохи конфигурации будет увеличиваться на 1. В значении эпохи конфигурации у каждого дозорного есть один и только один шанс установить дозорного в качестве лидера.
Чтобы выбрать ведущего дозорного, узлы дозорного кластера отправят друг другу команду is-master-down-by-addr, и команда принесет свой runId, что означает, что вы хотите установить себя в качестве местный лидер-страж, прямо над ним:
- Правила Sentinel для установки локальных лидеров-дозорных действуют в порядке очереди: исходный дозорный, который первым отправляет запрос на настройку целевому дозорному, станет локальным лидером целевого дозорного, а все запросы на настройку, полученные впоследствии, будут отклонены целевым дозорным. целевой часовой
- Ответ целевого дозорного элемента включает параметр Leader_runId и Leader_epoch, а в подтаблице указан локальный идентификатор запуска лидера и эпоха конфигурации целевого дозорного элемента.
- После того, как Sentinel-источник получил ответ на команду, он проверит, совпадает ли значение Leader_epoch, если совпадает, то SENTINEL-источник продолжает удалять параметры Leader_Runid в ответе, если значение параметра Leader_Runid соответствует, то целевой Sentinel устанавливает исходный Sentinel в качестве локального ведущего Sentinel
- Если Sentinel установлен в качестве местного ведущего Sentinel, то этот Sentinel становится ведущим SENTINEL; если ни один Sentinel не выбран в качестве ведущего Sentinel, то через некоторое время каждый Sentinel снова сделает выбор.
3.2.3.2 Отказоустойчивость
После того, как лидер Sentinel выбран, лидер Sentinel выполнит операцию аварийного переключения на автономном главном сервере.Отработка отказа в основном включает три этапа:
- Выборы хозяина: выбрать раба и превратить его в хозяина
- Настройте все подчиненные серверы под автономным главным сервером для репликации нового главного сервера.
- Если исходный автономный главный сервер возвращается в оперативный режим, сделайте его подчиненным сервером нового главного узла.
3.2.3.2.1 Выбор нового основного сервера
Чтобы выбрать подчиненный сервер, который находится в хорошем состоянии и имеет полные данные, ведущий дозорный будет использовать определенные правила для очистки выборки (перед очисткой ведущий дозорный сохранит подчиненные узлы исходного мастера в виде списка):
- В соответствии с онлайн-статусом узла: офлайн-ведомый узел напрямую удаляется из списка.
- В соответствии с состоянием сети узла: удалить из списка все подчиненные серверы, которые были отключены от автономного главного сервера более чем на миллисекунды * 10 миллисекунд; если время отключения между подчиненной библиотекой и главной библиотекой превышает пороговое значение , это означает, что это ведомое устройство. Ситуация с сетью узла не очень хорошая.
3.2.3.2.2 Уведомление
Когда появляется новый главный сервер, следующим шагом для ведущего дозорного является разрешение всем подчиненным серверам автономного главного сервера копировать новый главный сервер.Это действие фактически выполняет операцию ассоциации ведущий-ведомый.Подробный процесс, Обратитесь к предыдущему разделу ведущий-ведомый.
3.3 Резюме
- Master-Slave Switching не выполняется, случайным образом выбирая Sentinel, но с помощью арбитража для голосования выбирать лидера, который отвечает за мастер-подчиненный выключатель
- Sentinel отправляет команды Ping в экземпляры (включая основные серверы, ведомые серверы и другие Sentinels) на частоте раз в секунду и определяют, является ли экземпляр в сети в соответствии с ответом экземпляра на команду Ping. Когда ответ недействителен, Sentinel будет судить об этом в качестве субъективного оффлайн