Предыдущий«Алгоритм согласованного хеширования в распределенном кэше данных»В статье описаны основные принципы и реализация алгоритма последовательного хеширования.Сегодня я возьму в качестве примера Redis Cluster, чтобы подробно объяснить шардинг данных в кэше распределенных данных, миграцию данных при переходе в онлайн и офлайн и перенаправление запросов.
Введение в кластер Redis
Redis Cluster — это распределенное решение для Redis, которое было официально запущено в версии 3.0 и эффективно отвечает требованиям Redis к распределению.
Кластер Redis обычно состоит из нескольких узлов, а количество узлов составляет не менее 6, чтобы обеспечить полный и высокодоступный кластер, три из которых являются главными узлами, а три — подчиненными узлами. Три главных узла будут выделять слоты для обработки командных запросов клиентов, в то время как подчиненные узлы могут заменить главный узел после отказа главного узла.
Как показано на рисунке выше, кластер содержит 6 узлов Redis, 3 ведущих и 3 подчиненных, а именно M1, M2, M3, S1, S2, S3. Помимо репликации данных между ведущими и подчиненными узлами Redis, все узлы Redis взаимодействуют друг с другом с помощью протокола Gossip для обмена и хранения информации о метаданных узла.
Как правило, главный узел Redis обрабатывает операции чтения и записи для клиентов, а подчиненные узлы обрабатывают только операции чтения.
стратегия разделения данных
Важнейшим моментом в решении распределенного хранения данных является шардирование данных, так называемое шардирование.
Для того, чтобы кластер мог расширяться по горизонтали, первая проблема, которую необходимо решить, заключается в том, как распределить весь набор данных на несколько узлов в соответствии с определенными правилами.Обычно используемые методы сегментирования данных включают в себя: сегментирование диапазона, сегментирование хэша, последовательные алгоритмы хэширования, хеширование. слоты и т.д.
Разделение диапазона предполагает, что набор данных упорядочен, и объединяет данные в смежном порядке, что может хорошо поддерживать операции обхода. Недостаток сегментирования диапазона заключается в том, что при последовательной записи возникают горячие точки. Например, для записи типа журнала порядок журналов обычно связан со временем, а время монотонно увеличивается, поэтому активная точка записи всегда находится в последнем сегменте.
Для реляционных баз данных в основном используется стратегия сегментирования диапазона, поскольку часто требуется сканирование таблиц или индексов.
Алгоритмы хэширования и последовательного хеширования были рассмотрены в предыдущей статье, о них могут узнать заинтересованные студенты.«Алгоритм согласованного хеширования в распределенном кэше данных». Далее мы в основном рассмотрим стратегию виртуальных хеш-слотов Redis.
Redis Cluster использует разделение виртуальных хеш-слотов, и все ключи сопоставляются с целыми слотами от 0 до 16383 в соответствии с хэш-функцией. Формула расчета: слот = CRC16 (ключ) и 16383. Каждый узел отвечает за поддержку части слота и данных ключ-значение, отображаемых слотом.
Особенности разделов виртуальных слотов Redis:
- Разделение связи между данными и узлами упрощает сложность расширения и сжатия узла.
- Сам узел поддерживает отношение сопоставления слота и не требует, чтобы клиент или прокси-служба поддерживали метаданные раздела слота.
- Поддерживает сопоставление запросов между узлами, слотами и ключами для маршрутизации данных, онлайн-масштабирования кластера и других сценариев.
Redis Cluster предоставляет гибкие решения для расширения и сокращения узлов. Не затрагивая внешние службы кластера, вы можете добавлять узлы в кластер для увеличения емкости или отключать некоторые узлы для уменьшения емкости. Можно сказать,Слот — это базовая единица для управления данными в кластере Redis., масштабирование кластера — это перемещение слотов и данных между узлами.
Давайте сначала рассмотрим принцип масштабирования кластера Redis. Затем узнайте, как обеспечить доступность кластера во время переноса данных узла Redis или восстановления после сбоя.
Развернуть кластер
Чтобы читатели могли лучше понять операцию расширения при подключении к сети, мы моделируем весь процесс с помощью команд Redis Cluster.
Когда новый узел Redis запускается и присоединяется к существующему кластеру, нам необходимо перенести для него слоты и данные. Во-первых, укажите план миграции слотов для нового узла, чтобы гарантировать, что каждый узел будет отвечать за одинаковое количество слотов после миграции, чтобы обеспечить единообразие данных этих узлов.
- Сначала запустите узел Redis, обозначенный как M4.
- Используйте команду Cluster Meet, чтобы позволить новому узлу Redis присоединиться к кластеру. Новый узел в начале находится в состоянии master node, так как нет ответственного слота, он не может принимать какие-либо операции чтения и записи, позже мы проведем миграцию слота и заполним его данными.
- Кластер передачи устанавливает слот {slot}, импортирующий {sourceNodeId} командный узел M4, чтобы целевой узел был готов к импорту слота данных.
- Отправьте команду cluster setslot { slot } migrating { targetNodeId} на исходные узлы, а именно на узлы M1, M2 и M3, чтобы исходный узел подготовился к переносу данных из слота.
- Исходный узел выполняет команду cluster getkeysinslot { slot } { count }, чтобы получить ключи count, принадлежащие слоту { slot }, а затем выполняет операцию на шаге 6 для переноса данных "ключ-значение".
- Выполните команду migrate { targetNodeIp} " " 0 { timeout } keys { key... } на исходном узле и перенесите полученные ключи на целевой узел пакетами с помощью механизма конвейера. Версия команды migrate для пакетной миграции: в Redis 3.0.6 или более поздней версии.
- Повторяйте шаги 5 и 6, пока все данные пары "ключ-значение" в слоте не будут перенесены на целевой узел.
- Отправьте команду cluster setslot { slot } node { targetNodeId } всем главным узлам в кластере, чтобы уведомить, что слот назначен целевому узлу. Чтобы обеспечить своевременное распространение изменений сопоставления узлов слотов, необходимо пройти и отправить все главные узлы для обновления перенесенных слотов для выполнения нового узла.
уменьшить кластер
Чтобы сжать узел, нужно перевести узел Redis в автономный режим.Весь процесс требует следующего рабочего процесса.
- Во-первых, необходимо подтвердить, есть ли у автономного узла ответственный слот.Если это так, вам необходимо перенести слот на другие узлы, чтобы обеспечить целостность всего сопоставления узла слота кластера после того, как узел отключится.
- Когда автономный узел больше не отвечает за слот или является подчиненным узлом, он может уведомить другие узлы в кластере, чтобы они забыли об автономном узле.Когда все узлы забывают сменить узел, их можно отключить в обычном режиме.
Автономному узлу необходимо перенести слот, за который отвечает узел, на другие узлы.Принцип такой же, как и процесс миграции слота предыдущего расширения узла.
После миграции слота также необходимо уведомить все узлы в кластере о том, что они забыли об автономном узле, а это означает, что другие узлы больше не будут обмениваться сплетнями с узлом, который находится в автономном режиме.
Кластер Redis использует команду cluster забыли { downNodeId }, чтобы добавить указанный узел в список отключенных, и узлы в списке отключенных больше не будут отправлять сообщения Gossip.
Маршрутизация клиентов
В режиме кластера, когда узел Redis получает какую-либо команду, связанную с ключом, он сначала вычисляет слот, соответствующий ключу, а затем находит соответствующий узел в соответствии со слотом.Если узел является самим собой, он обрабатывает команду ключа, в противном случае он отвечает ошибкой перенаправления MOVED и информирует клиентский запрос о правильном узле. Этот процесс называется перенаправлением MOVED.
***Следует отметить, что Redis не просто вычисляет содержимое значения ключа при вычислении слота.Когда содержимое значения ключа включает фигурные скобки, вычисляется только содержимое внутри скобок. ***Например, если используется ключ user:{10000}:books, при расчете хеш-значения будет рассчитано только 10000.
Пример ошибки MOVED выглядит следующим образом: клавишаxвладение хеш-слотом3999, а также IP и номер порта узла, ответственного за обработку этого слота127.0.0.1:6381. Клиенту необходимо повторно отправить запрос команды GET на узел, которому он принадлежит, на основе IP-адреса и номера порта.
GET x
-MOVED 3999 127.0.0.1:6381
Поскольку перенаправление запросов увеличивает нагрузку на операции ввода-вывода, это неэффективный способ использования Redis Cluster, а использование Smart Cluster Client. Поддерживая внутреннее отношение сопоставления между слотами и узлами Redis, клиент Smart может выполнять поиск по ключу к узлу локально, тем самым максимально повышая эффективность ввода-вывода, в то время как перенаправление MOVED отвечает за помощь клиенту в обновлении отношения сопоставления.
Redis Cluster поддерживает онлайн-миграцию слотов и данных для завершения горизонтального масштабирования.Когда данные, соответствующие слоту, переносятся с исходного узла на целевой, клиенту необходимо выполнить интеллектуальную миграцию, чтобы обеспечить нормальное выполнение ключевых команд. Например, когда данные слота переносятся с исходного узла на целевой узел, часть данных может находиться на исходном узле, а другая часть — на целевом узле.
Поэтому, учитывая вышеописанную ситуацию, процесс выполнения клиентской команды выглядит следующим образом:
- Клиент отправляет команду на узел-источник по данным локального кеша слота, если есть соответствующий ей ключ, она будет выполнена напрямую, а результат будет возвращен клиенту.
- Если узел возвращает ошибку MOVED, обновите сопоставление между локальным слотом и узлом Redis, а затем повторно инициируйте запрос.
- Если данные переносятся, узел ответит исключением перенаправления ASK. Формат следующий: ( ошибка ) ASK { слот } { targetIP } : {targetPort}
- Клиент извлекает информацию о целевом узле из исключения перенаправления ASK, отправляет запрашивающую команду целевому узлу, чтобы открыть идентификатор клиентского соединения, а затем выполняет ключевую команду.
Хотя ASK и MOVED являются элементами управления перенаправлением для клиента, они имеют существенные отличия. Перенаправление ASK указывает, что кластер находится в процессе миграции данных слота, и клиент не может знать, когда миграция завершена, поэтому это может быть только временное перенаправление, и клиент не будет обновлять кеш сопоставления из слота в Redis. узел. Однако перенаправление MOVED указывает на то, что слот, соответствующий ключу, был явно назначен новому узлу, поэтому кэш сопоставления слота с узлом Redis необходимо обновить.
отказоустойчивость
Когда небольшое количество узлов в кластере Redis выходит из строя, автоматический переход на другой ресурс гарантирует, что кластер сможет нормально предоставлять внешние службы.
Когда узел Redis объективно находится в автономном режиме, кластер Redis выберет главный, чтобы заменить его из своих подчиненных узлов, тем самым обеспечив высокую доступность кластера. Это содержание не является основным содержанием этой статьи, и заинтересованные студенты могут изучить его самостоятельно.
Однако есть одно предостережение. По умолчанию весь кластер недоступен, если ни один из слотов 16384 кластера не назначен узлу. Выполнение любой ключевой команды возвращает команду CLUSTERDOWN Hash slot not serve.При отключении мастер-ноды, удерживающей слот, весь кластер недоступен в период с момента обнаружения неисправности до автоматического завершения переноса.Для большинства предприятий такая ситуация недопустима, поэтому рекомендуется настроить параметр cluster-require -full-coverage в нет.Когда главный узел выходит из строя, это влияет только на выполнение соответствующих команд для слота, за который он отвечает, и не влияет на доступность других главных узлов..
Ссылаться на
- «Разработка и эксплуатация Redis»
- nuggets.capable/post/684490…
- С Aol на.com/Redis/Redis…
- Экспресс-плата 5000.com/2017/04/17/…