Больше отличных статей.
«Микросервисы — это не все, а лишь подмножество определенного домена».
С таким количеством компонентов мониторинга всегда найдется подходящий для вас
«С Нетти, что мы разрабатываем? 》
«Вероятно, это наиболее подходящая спецификация Redis».
«Портрет программиста, десять лет взлетов и падений»
Самая полезная серия:
«Наиболее часто используемый набор навыков «vim» в производственной среде Linux.
«Наиболее часто используемый набор навыков «Sed» в производственной среде Linux.
«Наиболее часто используемый набор навыков «AWK» в производственной среде Linux.
Если вы согласны с этими знаниями, приглашаем обратить внимание на вкус Miss Sister в публичном аккаунте WeChat.
ID: xjjdog
Автор обслуживал тысячи экземпляров Redis. Эти экземпляры используют простую структуру master-slave. Кластерное решение состоит в основном из клиентских jar-пакетов. Поначалу мне не очень нравился кластер redis, потому что его маршрутизация слишком жесткая, а его эксплуатация и обслуживание сложны. Почему вы так говорите, можете сослаться на предыдущую статью«Правила маршрутизации в реальности могут быть более сложными, чем вы себе представляете»..
Но чиновник проталкивает эту штуку, которой суждено получить все более широкое распространение, которую можно найти на обычных биржах. Хотя есть такие-то и такие-то недостатки, но они не могут сопротивляться приливу авторитета. Поскольку кластер Redis становится все более и более стабильным, пришло время обменяться душой с кластером Redis.
Введение
Кластер Redis — это собственное кластерное решение, в настоящее время достигнут большой прогресс в плане высокой доступности и стабильности. Согласно статистике и наблюдениям, все больше компаний и сообществ перенимают кластерную архитектуру redis, ставшую стандартом де-факто. Его главная особенность — децентрализация и отсутствие необходимости в прокси. Одной из основных целей проектирования является достижение линейной масштабируемости.
Просто полагаться на сам кластерный сервер Redis не может выполнять официально обещанные функции. В широком смысле кластер Redis должен включать как серверы Redis, так и клиентские реализации, такие как jedis. Они единое целое.
Распределенное хранилище — это не что иное, как обработка шардов и реплик.Для Redis Cluster основным понятием является слот (slot), разбираясь в нем, в основном понимает метод управления кластером.
Преимущества и недостатки
После понимания этих особенностей эксплуатация и техническое обслуживание на самом деле упрощаются. Давайте сначала рассмотрим более очевидные преимущества и недостатки.
преимущество
1. Дополнительные кластеры Sentinel больше не требуются, предоставляя пользователям согласованное решение и снижая затраты на обучение.
2. Децентрализованная архитектура, одноранговые узлы и кластер могут поддерживать тысячи узлов.
3. Концепция слота абстрагируется, и операции по эксплуатации и обслуживанию выполняются для слота.
4, функция копирования позволяет автоматическиму переключению, в большинстве случаев без вмешательства человека.
недостаток
1. Клиенту необходимо кэшировать некоторые данные и реализовать протокол Cluster, что относительно сложно.
2. Данные реплицируются асинхронно, поэтому невозможно гарантировать строгое соответствие данных.
3. Изоляция ресурсов затруднена, а трафик часто несбалансирован, особенно когда несколько служб совместно используют кластер. Данные неизвестно куда, а для горячих данных пройти не могут专项优化Заканчивать.
4. Ведомая библиотека представляет собой полную холодную резервную копию и не может совместно использовать операции чтения, что на самом деле является пустой тратой времени. Требуется дополнительная работа.
5. Поддержка MultiOp и Pipeline ограничена.Если старый код обновляется, будьте осторожны.
6. Перенос данных основан на ключе, а не на слоте, и этот процесс медленный.
Фундаментальный
Из канавки к ключу процесс позиционирования, очевидно, двойная маршрутизация.
маршрутизация ключей
Кластер Redis не имеет ничего общего с обычно используемым непротиворечивым хэшем, он в основном использует концепцию хеш-слота. Когда в нем нужно получить доступ к ключу, клиент Redis сначала будет использовать ключcrc16Алгоритм вычисляет значение и модулирует это значение.
crc16(key)mod 16384
Простой принцип сервера
Как упоминалось выше, кластер Redis определяет в общей сложности 16384 слота, и все операции кластера кодируются вокруг данных этих слотов. Сервер использует простой массив для хранения этой информации.
Для суждения используйте BitMap для хранения наиболее разнесенных. Redis Cluster должен использовать массив с именем Slot, чтобы сохранить, удерживает ли текущий узел этот слот.
Как показано на рисунке, длина этого массива составляет 16384/8=2048 байт, поэтому вы можете использовать 0 или 1, чтобы определить, есть ли у этого узла слот.
Когда все 16384 слота в базе данных обработаны узлами, кластер находится в сети (в порядке); и наоборот, если какой-либо слот в базе данных не обработан, кластер находится в автономном режиме (сбой).
Когда клиент отправляет соответствующую команду узлу, узел, получивший команду, вычислит, к какому слоту принадлежит ключ, подлежащий обработке командой, и проверит, назначен ли этот слот себе. Если он не свой, он направит клиента к нужному узлу.
Таким образом, клиент может завершить операцию, подключившись к любой машине в кластере.
Установите кластер из 6 узлов
Готов к работе
Если нам нужно собрать кластер из 3 срезов, у каждого среза есть копия. Тогда требуется 3 * 2 = 6 экземпляров узла. Redis может начать с указания файла конфигурации, что мы делаем, так это модифицируем файл конфигурации.
Скопируйте 6 файлов конфигурации по умолчанию.
for i in {0..5}
do
cp redis.conf redis-700$i.conf
done
Модифицируем содержимое конфигурационного файла, в качестве примера возьмем redis-7000.conf, мы хотим включить его кластерный режим.
cluster-enabled yes
port 7000
cluster-config-file nodes-7000.conf
nodes-7000.conf сохранит некоторую информацию о кластере на текущем узле, поэтому он должен быть независимым.
Вкл выкл
Опять же, мы используем скрипт для его запуска.
for i in {0..5}
do
nohup ./redis-server redis-700$i.conf &
done
Чтобы продемонстрировать, мы отложили насилие.
ps -ef| grep redis | awk '{print $2}' | xargs kill -9
Комбинированный кластер
Мы используем redis-cli для составления кластера. Redis автоматизирует этот процесс. Эта серия процессов объединяется путем отправки инструкций каждому узлу.
./redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
Несколько передовых принципов
Сбой узла
Каждый узел в кластере будет периодически отправлять сообщения проверки связи другим узлам в кластере, чтобы определить, находится ли другая сторона в сети.Если узел, получающий сообщение проверки связи, не возвращает сообщение проверки связи в течение заданного времени, то узел, отправляющий сообщение проверки связи Будут ли узлы, которые получают сообщения ping, будут помечены как подозрительные в автономном режиме (PFAIL).
Если в кластере более половины узлов сообщают о главном узле x как о подозрении в отключенном состоянии, то главный узел x будет помечен как отключенный (FAIL), а узел, помеченный x как FAIL, отправит сообщение в кластер. сообщение FAIL x, все узлы, получившие это сообщение FAIL, немедленно пометят x как FAIL.
Мы можем отметить этот процесс, похожий на узел zk es и суждения, составляют более половины его судить, поэтому количество основных узлов, как правило, нечетным. В отсутствие большинства небольших групп конфигурации, в теории, имеют раскол мозга (временно не встречаются).
главный-ведомый переключатель
Когда узел обнаруживает, что его главный узел перешел в состояние сбоя, он выбирает один из подчиненных узлов этого узла и выполняет его.slaveof no oneкоманда, чтобы стать главным узлом.
После того, как новый узел завершает назначение своего слота, он широковещательно передает сообщение pong в кластер, чтобы немедленно сообщить другим узлам о своих изменениях. Он сообщает другим: я уже являюсь главным узлом, и я взял на себя управление рассматриваемым узлом и стал его заместителем.
Управление кластером в Redis широко использует эти уже определенные инструкции. Так что эти инструкции предназначены не только для нас, чтобы использовать их из командной строки, но и для самого redis.
синхронизация данных
Когда ведомое устройство подключается к ведущему, оно отправляет команду синхронизации. После того, как мастер получит эту команду, он запустит процесс сохранения в фоновом режиме. После завершения выполнения мастер передает весь файл базы данных на слейв, тем самым завершая первую полную синхронизацию.
Затем мастер по очереди передает инструкции по изменению, которые он получает, ведомому, чтобы добиться окончательной синхронизации данных. Начиная с Redis 2.8, поддерживается возобновление репликации master-slave через точку останова.Если сетевое соединение прерывается в процессе репликации master-slave, вы можете продолжить копирование с того места, откуда вы его скопировали в последний раз, вместо копирования с нуля.
данные потеряны
Между узлами в кластере Redis используется асинхронная репликация, и нет концепции ack, подобной kafka. Узлы обмениваются информацией о статусе через протокол сплетен и используют механизм голосования для завершения повышения роли от ведомого до ведущего, что требует времени для завершения этого процесса. Windows может существовать во время процесса сбоя, что приводит к потере записанных данных. Например, следующие две ситуации.
1. Команда дошла до ведущего.В это время данные не были синхронизированы со ведомым.Мастер ответит клиенту ok. Если главный узел выйдет из строя в это время, эти данные будут потеряны. Сделав это, Redis избежит многих проблем, но это невыносимо для системы, требующей высокой надежности данных.
2. Поскольку таблица маршрутизации хранится на стороне клиента, возникает проблема устаревания. Если раздел делает узел недоступным, ведомый узел повышается, но исходный главный узел в это время снова доступен (отказоустойчивость не была завершена). В это время, если таблица маршрутизации клиента не будет обновлена, он будет записывать данные не на тот узел, что приведет к потере данных.
Таким образом, хороший кластер Redis работает в нормальных условиях, в крайних случаях возникает проблема с потерей некоторой ценности, решения в настоящее время нет.
Комплексная эксплуатация и обслуживание
Эксплуатация и обслуживание кластера Redis очень сложны, несмотря на то, что он абстрагирован, процесс все еще не прост. Некоторыми инструкциями можно уверенно пользоваться только после подробного понимания принципа их реализации.
Есть две точки входа для эксплуатации и обслуживания.Один из них — использовать redis-cli для подключения к любому из них, а затем отправитьclusterКоманда в начале, большая часть этой части команды предназначена для работы со слотом.Конкретная логическая комбинация в начале кластера, неоднократно вызывает эти команды выполнены.
Другая запись - использовать команду redis-cli, плюс--clusterпараметры и директивы. Эта форма в основном используется для управления информацией об узлах кластера., такие как добавление или удаление узлов. Поэтому этот метод рекомендуется.
Кластер Redis предоставляет очень сложные команды, с которыми трудно работать и которые трудно запомнить. Для управления рекомендуется использовать такой инструмент, как CacheCloud.
Ниже приведены несколько примеров.
Отправив команду CLUSTER MEET узлу A, клиент может сделать так, чтобы узел A, получивший команду, добавил еще один узел B в кластер, где в данный момент находится узел A:
CLUSTER MEET 127.0.0.1 7006
С помощью команды cluster addlots узлу можно назначить один или несколько слотов.
127.0.0.1:7000> CLUSTER ADDSLOTS 0 1 2 3 4 . . . 5000
Установите подчиненный узел.
CLUSTER REPLICATE <node_id>
redis-cli --cluster
redis-trib.rb — официальный инструмент управления Redis Cluster, но в последней версии рекомендуется использовать redis-cli для операций.
Добавить новый узел в кластер
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7007 --cluster-replicas 1
Удалить узел из кластера
redis-cli --cluster del-node 127.0.0.1:7006 54abb85ea9874af495057b6f95e0af5776b35a52
Перенос слотов на новые узлы
redis-cli --cluster reshard 127.0.0.1:7006 --cluster-from 54abb85ea9874af495057b6f95e0af5776b35a52 --cluster-to 895e1d1f589dfdac34f8bdf149360fe9ca8a24eb --cluster-slots 108
Есть много похожих команд.
создать: создать кластер
check: Проверить кластер
информация: просмотр информации о кластере
исправить: исправить кластер
reshard: миграция онлайн слотов
перебалансировка: сбалансируйте количество слотов узлов кластера
add-node: добавить новый узел
del-узел: удалить узел
set-timeout: Установите период тайм-аута узла
вызов: выполнить команду на всех узлах в кластере
импорт: импортировать внешние данные Redis в кластер
Обзор других решений
режим ведущий-ведомый
Самый ранний из поддерживаемых Redis — это режим MS, то есть один ведущий и несколько подчиненных. Одномашинный qps Redis может достигать 10 Вт+, но в некоторых сценариях с высоким трафиком этого все еще недостаточно. Как правило, ведомые устройства увеличиваются за счет разделения чтения и записи, а нагрузка на хост снижается.
Поскольку это архитектура master-slave, она сталкивается с проблемами синхронизации.Синхронизация режима redis master-slave делится на полную синхронизацию и частичную синхронизацию. Когда ведомое устройство только что создано, выполнение полной синхронизации неизбежно. После завершения полной синхронизации перейдите к фазе добавочной синхронизации. Это ничем не отличается от кластера Redis.
Этот режим все еще относительно стабилен, но требует дополнительной работы. Пользователям необходимо разработать функцию переключения master-slave самостоятельно, то есть использовать дозорные для определения состояния работоспособности каждого экземпляра, а затем изменять состояние кластера с помощью инструкций.
Когда размер кластера увеличивается, режим ведущий-ведомый быстро сталкивается с узкими местами. Поэтому для расширения обычно используется метод хеширования на стороне клиента, включая согласованное хеширование, подобное memcached.
Однако, добавив такую функцию, как активное уведомление ZK, и сохранив конфигурацию в облаке, риск можно значительно снизить. Тысячи узлов redis, которые я обслуживал, управляются таким образом.
прокси-режим
Шаблоны кода были очень популярны до появления кластера Redis, такого как codis. Прокси-уровень имитирует себя как Redis, получает запрос от клиента, а затем выполняет фрагментацию и миграцию данных в соответствии с настраиваемой логикой маршрутизации, и бизнес-стороне не нужно изменять какой-либо код. В дополнение к плавному расширению, некоторые функции переключения ведущий-ведомый и FailOver также выполняются на прокси-уровне, и клиент может даже не иметь никакого представления. Такие программы также известны как распределенное промежуточное ПО.
Типичная реализация показана на рисунке ниже, а кластер redis за ней может быть даже смешанным.
Несколько прокси-серверов обычно используют lvs и другой внешний дизайн для балансировки нагрузки.Если на уровне прокси мало машин, а внутренний трафик redis высок, сетевая карта станет основным узким местом.
Nginx также можно использовать в качестве прокси-слоя redis, что называется более профессионально.Smart Proxy. Этот метод является более частичным, если вы лучше знакомы с nginx, это элегантный подход.
Используйте ограничения и ямы
Redis работает очень быстро. Как правило, чем быстрее что-то идет, тем больше последствий, когда что-то идет не так. Не так давно я написал спецификацию для Redis:«Вероятно, это наиболее подходящая спецификация Redis».. Спецификация такая же, как и архитектура, лучше всего подходит для среды вашей компании, но она даст некоторые основные идеи.
Строго запрещенные вещи - это вообще места, где предшественники наступали на ямы. В дополнение к содержанию этой спецификации для redis-кластера добавьте следующие пункты.
1. Кластер Redis заявляет, что может поддерживать 1k узлов, но лучше этого не делать. Когда количество узлов увеличивается до 10, вы можете почувствовать некоторый джиттер в кластере. Такой большой кластер доказывает, что ваш бизнес уже очень хорош.Рассмотрите возможность шардинга клиентов.
2. Обязательно избегайте хот-спотов.Если весь трафик попадает на определенный узел, последствия, как правило, очень серьезные.
3. Не ставьте редис для больших ключей, это будет генерировать много медленных запросов и повлияет на обычные запросы.
4. Если вы не используете его в качестве хранилища, для кеша должен быть установлен срок действия. Ощущение, что ты занимаешь подземелье и не покакаешь, очень раздражает.
5. Большой трафик, не открывайте aof, просто открывайте rdb.
6. В работе кластера redis используйте меньше конвейера и меньше мультиключей, они дадут много непредсказуемых результатов.
Выше приведены некоторые дополнения, более полную информацию можно найти в спецификации.«Вероятно, это наиболее подходящая спецификация Redis».. .
End
Кода redis совсем немного, и очень сложного распределенного энергоснабжения он точно не добьется. Позиционирование Redis — это производительность, горизонтальное масштабирование и доступность, которых достаточно для простых приложений общего трафика. Производственная среда — нетривиальный вопрос.Для сложных приложений с высокой степенью параллелизма она предназначена для комбинированного решения по оптимизации.