серия Redis: кластер

Node.js Redis задняя часть GitHub

1. Введение

Redis Cluster — это распределенная реализация Redis, которая представляет собой ячеистую структуру, в которой каждый узел подключен к каждому другому узлу через TCP-соединение. Теперь давайте посмотрим, каких целей достиг Redis Cluster?

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

Итак, кластерные среды Redis Redis с нераспределенной средой по функции ничем не отличаются?

  • База данных кластера только 0, и SELECT не поддерживает
  • Поскольку кластер распределяет ключи по разным слотам, операции репликации с участием нескольких значений ключа также не поддерживаются, например объединения и пересечения в наборе.

2 Концепция

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

2.1 Узлы

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

Имя узла - это шестнадцатеричное число 160 бит случайного случая, при этом случайное число получается при первом запуске узла (обычно с / dev / urandom). Он сохранит идентификатор узла в файле конфигурации, будущее всегда будет использовать этот идентификатор, есть два способа, если вы хотите заменить идентификатор.

  1. Удалите файл конфигурации узла.
  2. воплощать в жизньCLUSTER RESETЗаказ.

Итак, для чего нужен этот идентификатор узла?

Идентификатор узла используется для каждого узла. Изменения в IP-адресе узла или порте могут быть обнаружены по идентификатору узла.

Если IP или порт узла изменились, как другие узлы узнают об этом?

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

Какую информацию узлы знают друг о друге?

  • IP-адрес и номер TCP-порта узла.

  • Различные логотипы.

  • Хэш-слот, используемый узлом.

  • Время последней отправки ping-пакета с подключением к кластеру.

  • Последний раз, когда пакет pong был получен в ответ.

  • В прошлый раз не удалось идентифицировать узел.

  • Количество подчиненных узлов данного узла.

  • Если узел является подчиненным узлом, будет информация об идентификаторе главного узла. (Если это главный узел, эта информация устанавливается на 0000000...)

Мы можем использоватьCLUSTER NODESНекоторую из приведенной выше информации можно получить с помощью команды, как показано ниже

2.2 Слоты

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

Так что же определяет, где хранится ключ?

Ниже приведен алгоритм расчета места хранения ключей.

HASH_SLOT = CRC16(key) mod 16384

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

Поскольку все пространство ключей разделено на 16384 слота, как эти слоты распределяются по разным узлам?

Слоты могут быть разделены с помощью следующей команды

CLUSTER ADDSLOTS slot1 [slot2] … [slotN]

3 Создайте кластер Redis

3.1 Введение в кластерную среду

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

3.2 Изменить файл конфигурации

Конфигурация кластера следующая

################################ REDIS CLUSTER ###############################

cluster-enabled yes

cluster-config-file nodes-6379.conf

cluster-node-timeout 5000

cluster-enabledУказывает, следует ли включить режим кластера

cluster-conf-fileУказывает путь для сохранения файла конфигурации узла.

cluster-node-timeoutУказывает тайм-аут узла

Полный файл конфигурации находится по адресуGithub.com/raine Big / прийти ..., Нужно скачать

3.3 Конфигурация узла и запуск

Поскольку один сервер используется для запуска трех экземпляров Redis, конфигурация каждого узла немного отличается, например, номер порта, расположение файла, имя файла и т. д. Я не буду выкладывать здесь каждый файл конфигурации, на Github есть файлы конфигурации для главной ноды и двух подчиненных нод.

Я создаю папку кластера в папке redis, а затем создаю мастер-файл в папке кластера для хранения файла конфигурации главного узла master.conf и некоторых других файлов, затем создаю два файла подчиненных узлов 7001 и 7002, а также сохраняю файлы конфигурации, и Т. Д.

mkdir cluster
cd cluster
mkdir master 7001 7002

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

3.4 Использование инструмента командной строки кластера redis-trib

У нас уже запущено девять экземпляров Redis, и нам нужно использовать эти экземпляры для создания кластера. Инструмент командной строки кластера redis-trib предоставляется в Redis для упрощения операций с кластером.

Перед выполнением файла redis-trib.rb вам необходимо установить среду ruby.Если это проблематично, вы можете напрямую запустить следующую команду

yum install centos-release-scl-rh
yum install rh-ruby23 -y
scl enable rh-ruby23 bash
gem install redis

Примечание: если работает напрямуюyum install rubyкоманду, затем запуститеgem install redisпокажетredis requires Ruby version >= 2.2.2Ошибка

Выполните команду следующим образом

./redis-trib.rb create --replicas 2 192.168.17.101:6379 192.168.17.102:6379 192.168.17.103:6379 192.168.17.101:7001 192.168.17.101:7002 192.168.17.102:7001 192.168.17.102:7002 192.168.17.103:7001 192.168.17.103:7002

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

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

Далее пользователю необходимо ввести yes для подтверждения

После ввода «да» redis-trib применит эту конфигурацию к кластеру, позволяя каждому узлу взаимодействовать друг с другом и, наконец, получит следующую информацию:

Когда выходные данные загружены, это означает, что среда кластера настроена.

[OK] All 16384 slots covered

Далее введитеcluster infoКоманда для просмотра состояния кластера, вывод выглядит следующим образом

3.5 Процесс настройки кластера

При создании кластера с redis-trib мы не знаем, что у него внутри происходит, поэтому кратко опишу процесс.

  1. Получив команду redis-trib для создания кластера, проверьте, больше или равно ли количество входящих мастер-узлов 3. Только более 3 узлов могут образовывать кластер.
  2. Рассчитайте количество слотов, которые необходимо выделить каждому главному узлу, и назначьте подчиненные узлы главному узлу.
  3. Вывести назначенную информацию и дождаться ввода пользователяyesПодтвердите план распределения.
  4. пользовательский вводyesПосле этого они начали план распределения.
  5. Укажите слот выделения основного узла.
  6. Ведомый узел копирует главный узел.
  7. Пусть узлы присоединяются к одному и тому же кластеру. (отправить команду встречи кластера)

Общий процесс описан выше.Далее мы представим команду кластера.

3.6 Команда ВСТРЕЧА ГРУЗОВ

Когда команда CLUSTER MEET не используется, каждый узел независим друг от друга, и все они находятся в кластере, содержащем только себя. С помощью команды CLUSTER MEET каждый независимый узел может быть соединен для формирования кластера, содержащего несколько узлов. Формат использования команды CLUSTER MEET следующий:

CLUSTER MEET <ip> <port>

Посмотрите на реализацию этой команды

3.7 Реализация команды Cluster Meet

Сценарий: есть два узла A (192.168.17.101) и B (192.168.17.102), вход на клиенте узла BCLUSTER MEET 192.168.17.101 6379, что указывает на то, что B присоединяется к кластеру, в котором находится A. Получив заказ, А начинает выполнять следующие шаги

  1. Узел A создает структуру узлов для B и добавляет ее в свой собственный словарь узлов.
  2. Узел A отправляет сообщение MEET узлу B (сообщение будет объяснено позже)
  3. Когда узел B получает сообщение MEET от узла A, узел B также создает структуру узла для A и добавляет ее в свой собственный словарь узлов.
  4. Узел B Ответы с сообщением понга в узле A.
  5. Когда узел A получает сообщение PONG, на которое отвечает узел B, это означает, что узел B успешно получил отправленное им сообщение MEET.
  6. В это время узел A вернет сообщение PING узлу B.
  7. Когда узел B получает сообщение PING, возвращенное узлом A, рукопожатие завершается.

Процесс рукопожатия узла выглядит следующим образом

4 Обнаружение отказа и передача

Это имитирует отказ главного узла, отправляя главный узелDEBUG SEGFAULTНеспособность добиться эффекта командного главного узла.

Выполнить на главном узле 101DEBUG SEGFAULTПосле команды заходим в клиент 103 для просмотра статуса ноды

Из приведенного выше рисунка видно, что главный узел 101 имеет больше отказных состояний, а подчиненный узел 7001 из 103 стал главным узлом. Теперь снова подключите 101 и снова проверьте статус.

Видно, что предыдущий 101 главный узел стал подчиненным узлом. Хорошо, посмотримКак кластер обнаруживает неисправности?иКак выйти из строяиз.

4.1 Обнаружение неисправностей

Как кластер обнаруживает, что узел неисправен?

О: Его можно разделить на следующие этапы.

Определение: узел, отправляющий сообщение PING --> узел A; узел, принимающий сообщение PING --> узел B.

  1. Узел в кластере отправляет сообщение PING узлу B.
  2. Если узел B не вNODE_TIMEOUTВозвращает сообщение PONG в течение времени, затем узел A помечает узел B как pfail ** (подозревается состояние линии)
  3. Узел A собирает информацию о состоянии узла B, идентифицированного большинством главных узлов в кластере, через поле сплетен.
  4. Если большинство мастеров отмечают Node B как PFAIL илиNODE_TIMEOUT *FAIL_REPORT_VALIDITY_MULTНа этот раз в состоянии PFAIL. Затем узел A пометит узел B как FAIL (автономное состояние).
  5. Узел A отправляет сообщение FAIL узла B всем доступным узлам.

4.2 Отказоустойчивость

Шаги аварийного переключения:

  1. Когда все подчиненные узлы главного узла отключены, будет выбран один подчиненный узел.

  2. Выбранный подчиненный узел будет выполнятьSLAVEOF no oneкоманда, чтобы стать новым главным узлом

  3. Новый мастер отменит все назначения слотов автономному мастеру и назначит все эти слоты себе.

  4. Новый главный узел отправляет в кластер сообщение PONG.Это сообщение может позволить другим узлам в кластере немедленно узнать, что этот узел изменился с подчиненного на главный узел и что главный узел взял на себя обработку, которая была изначально обрабатывается автономным узлом.

  5. Новый первичный узел начинает получать запросы команд, относящиеся к слоту, за обработку которого он отвечает, и аварийное переключение завершено.

Ниже приведено содержимое журнала сбоя

2169:M 31 Jul 21:06:20.873 * Marking node 3c29beb7984b40a8c19b580362a0daf29dc349fb as failing (quorum reached).
2169:M 31 Jul 21:06:20.873 # Cluster state changed: fail
2169:M 31 Jul 21:06:21.546 # Failover auth granted to aba761321b40112c0b8de29d810767a40c59d27b for epoch 10
2169:M 31 Jul 21:06:21.586 # Cluster state changed: ok
2169:M 31 Jul 21:13:05.849 * Clear FAIL state for node 3c29beb7984b40a8c19b580362a0daf29dc349fb: master without slots is reachable again.

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

Официальный сайт Redis:redis.io

Сайт Redis на китайском языке:www.redis.cn

Файл конфигурации кластера для этой статьи:Github.com/raine Big / прийти ...