1. Введение в Redis
www.redis.io
Redis — это база данных хранилища K-V в памяти. Поддерживаемые типы хранения: строка, список, набор, zset (отсортированный набор), хэш и т. д. Все эти типы данных поддерживают push/pop, add/remove, объединение и разность пересечений, а также более сложные операции, и эти операции являются атомарными. Redis поддерживает сортировку различными способами. В случае обеспечения эффективности данные кэшируются в памяти. В то же время Redis предоставляет стратегии постоянства.Разные стратегии запускают синхронизацию на диск или операции модификации записи в дополнительные файлы записей.На этой основе реализуется master-slave.
Это высокопроизводительная система хранения, которая может поддерживать более 100 тыс.+ частот чтения и записи в секунду. В то же время он также поддерживает публикацию/подписку на сообщения, что дает вам еще один вариант при построении высокопроизводительной системы очередей сообщений.
Redis поддерживает синхронизацию master-slave. Данные могут быть синхронизированы с главного сервера на любое количество подчиненных серверов, которые могут быть главными серверами, связанными с другими подчиненными серверами. Это позволяет Redis выполнять репликацию одноуровневого дерева. Данные могут быть записаны на диск преднамеренно или непреднамеренно. Поскольку механизм публикации/подписки полностью реализован, можно подписаться на канал и получить полную запись публикации сообщения с главного сервера при синхронизации дерева из любой точки базы данных. Синхронизация полезна для масштабируемости и избыточности данных для операций чтения.
2. Мастер-раб
Redis поддерживает режим ведущий-ведомый, один главный и несколько подчиненных, сервер Redis может устанавливать другие серверы Redis в качестве подчиненных, а подчиненные синхронизируют данные мастера. После настройки чтение и запись разделены, хост отвечает за чтение и запись сервисов, а ведомый отвечает только за чтение. Снизить нагрузку на хозяина. То, что реализует Redis, — это согласованность в конечном итоге, и выбор сильной или слабой согласованности зависит от бизнес-сценария.
Существует два способа (или два этапа) синхронизации master-slave redis: полная синхронизация и частичная синхронизация.
Когда главный и раб только подключен, выполняется полная синхронизация; после завершения полной синхронизации выполняется частичная синхронизация. Конечно, раб может инициировать полную синхронизацию в любое время, если это необходимо. Стратегия Redis - это то, что в любом случае она сначала попытается выполнить частичную синхронизацию. Если это неудачно, раб будет обязан выполнить полную синхронизацию и запуск BGSave ... после окончания BGSAVE, файл RDB будет передан ; если успешно, раб будет разрешен для выполнения частичной синхронизации и передачи данных в заднем плате. Проще говоря, синхронизация Master-Slave - это загрузка и загрузка файлов RDB; мастер имеет небольшую часть модификации данных, а запись модификации распространяется на каждый раб.
3. кластер Redis
Проблема с режимом master-slave заключается в том, что после того, как master выходит из строя, slave может только читать, но не писать, и не может гарантировать высокую доступность. Кластерная технология Redis является важным средством для создания высокопроизводительной архитектуры веб-сайта.Представьте, что, хотя веб-сайт находится под высоким давлением одновременного доступа, также необходимо запрашивать данные, которые соответствуют условиям, из массива данных и быстро реагировать.Мы должны подумайте о нарезке данных. , поместите данные на несколько разных серверных узлов в соответствии с определенными правилами, чтобы уменьшить нагрузку на серверы с одним узлом.
Redis Cluster использует бесцентровую структуру, каждый узел сохраняет данные и все состояние кластера, и каждый узел подключен ко всем другим узлам. Протокол сплетен используется между узлами для распространения информации и обнаружения новых узлов.
Redis Cluster — это распределенная, отказоустойчивая реализация Redis.Функции, которые могут использоваться кластером, представляют собой подмножество функций, которые может использовать обычный автономный Redis.
В Redis Cluster нет центральных узлов или прокси-узлов, и одной из основных целей проектирования кластера является достижение линейной масштабируемости.
Redis Cluster жертвует некоторой отказоустойчивостью ради согласованности: система сохраняет как можно больше, сохраняя при этом ограниченную устойчивость к разрывам сети и сбоям узлов.
4. Установка и развертывание
Установка Redis относительно проста, а официальный сайт загружает сжатый пакет и распаковывает его. Для режима кластера требуется среда компиляции ruby.Минимальная конфигурация кластера — 3 мастера.Если число меньше 3, при запуске кластера будет сообщено об ошибке.
редис версия: 3.2.4
4.1 Топология режима ведущий-ведомый
Топология режима ведущий-ведомый
В режиме «ведущий-ведомый» используется один ведущий и три подчиненных устройства.И ведущий, и подчиненный настроены с аутентификацией, а чтение и запись разделены.
Действия основного эксперимента:
1) Несколько приложений записываются одновременно, и измеряется скорость записи;
2) Несколько приложений записываются одновременно, и одновременно происходит процесс чтения, и измеряется скорость чтения и записи;
3) Главный хост не работает, а приложение все еще читает и пишет.
4.2 Схема топологии кластера выглядит следующим образом
cluster
Кластерный режим использует четыре ведущих и четыре подчиненных устройства, а также разделяет чтение и запись.
Действия основного эксперимента:
1) Мастер не работает, смотрите журнал, новый раб становится мастером;
2) После выхода из строя мастера перезапустите его, и мастер станет ведомым;
3) Кластер весь выключен, хост Redis перезапущен, а данные не потеряны.
5. Принцип
5.1 Последовательность
Filesnapshot: по умолчанию Redis сохраняет данные на диск в виде моментальных снимков.Формат в файле конфигурации: сохранить N M означает в течение N секунд, если Redis будет изменен не менее M раз, Redis сохранит моментальные снимки на диск.
Принцип работы: когда Redis необходимо выполнить постоянство, Redis разветвит дочерний процесс; дочерний процесс записывает данные во временный файл RDB на диске; когда дочерний процесс завершает запись временного файла, исходный RDB заменяется, как показано ниже. Преимущество в том, что это может быть копирование при записи.
Только добавление: когда метод моментального снимка файлов аварийно завершает работу, последние данные будут потеряны (количество потерянных данных зависит от конфигурации вашей стратегии сохранения), так что это его самый большой недостаток. Много. Метод Append-only может гарантировать, что все данные не будут потеряны, но производительность redis хуже. AOF может быть постоянным на протяжении всего процесса.Его нужно только включить в файле конфигурации (по умолчанию нет).После включения appendonly yes redis будет добавлять его в файл aof каждый раз, когда redis выполняет команду для изменения данных.Когда Redis перезапускается, файл AOF будет прочитан для «воспроизведения» для восстановления Последний момент перед закрытием Redis.
Есть три способа обновить файлы AOF, обратитесь к параметру конфигурации appendfsync:
- appendfsync всегда вызывает fsync для обновления файла AOF каждый раз, когда отправляется команда модификации, что очень, очень медленно, но также очень безопасно;
- appendfsync Everysec вызывает fsync каждую секунду для обновления файла AOF, что очень быстро, но может привести к потере данных в течение одной секунды;
- appendfsync не полагается на обновление ОС, Redis не обновляет активно AOF, это самый быстрый, но с плохой безопасностью. По умолчанию рекомендуется обновлять каждую секунду, чтобы учитывать и скорость, и безопасность.
Ведомые устройства также могут принимать запросы на подключение и синхронизацию от других ведомых устройств, что может эффективно снять нагрузку синхронизации со стороны ведущего устройства. Таким образом, мы можем думать об архитектуре репликации Redis как о структуре графа.
Главный сервер обслуживает подчиненные без блокировки. Таким образом, во время синхронизации Master-Slave клиенты по-прежнему могут отправлять запросы или изменять запросы.
Ведомый сервер также выполняет неблокирующую синхронизацию данных. Во время синхронизации, если клиент отправляет запрос на запрос, Redis возвращает данные перед синхронизацией.
Для того, чтобы разгрузить мастер-сервер от операций чтения, подчиненный сервер может предоставить клиенту услуги только для чтения, а сервис записи все равно должен выполняться мастером. Несмотря на это, масштабируемость системы была значительно улучшена.
Мастер может передать операцию сохранения данных ведомым устройствам, тем самым избегая необходимости отдельного процесса в ведущем устройстве для завершения этой операции.
Redis находится в неблокирующем режиме на ведущем устройстве, то есть когда ведомое устройство выполняет синхронизацию данных, ведущее устройство может принять запрос клиента, не влияя на согласованность синхронизированных данных, однако оно находится в режиме блокировки на ведомой стороне, и ведомое устройство синхронизирует основные данные, не может отвечать на запросы клиентов.
5.2 Как работает репликация
(1) Ведомый сервер подключен к главному серверу.
(2) Ведомый сервер отправляет команду SYCN.
(3) Главный сервер создает резервную копию базы данных в файле .rdb.
(4) Главный сервер передает файл .rdb на подчиненный сервер.
(5) Подчиненный сервер импортирует данные файла .rdb в базу данных.
После того, как ведомое устройство запустится и подключится к ведущему, оно будет активно отправлять команду SYNC. После этого Мастер запустит процесс фонового сохранения и соберет все полученные команды для модификации набора данных.После выполнения фонового процесса Мастер передаст весь файл базы данных на Слейв для завершения полной синхронизации. Ведомый сервер сохраняет данные файла базы данных и загружает их в память после получения. После этого Мастер продолжает передавать все собранные команды модификации и новые команды модификации ведомым по очереди, и ведомые на этот раз будут выполнять эти команды модификации данных, чтобы добиться окончательной синхронизации данных. Если связь между Мастером и Слейвом разорвана, Слэйв может автоматически переподключиться к Мастеру, но после успешного подключения автоматически будет выполнена полная синхронизация.
5.3 Непротиворечивое хеширование
Цель кластера — распределить разные ключи по разным узлам redis.Здесь нам нужно правило или алгоритм.Обычный метод — получить хэш-значение ключа, а затем вычислить модуль по количеству узлов, но это метод Есть очевидные недостатки.Когда нам нужно увеличить или уменьшить узел, это приведет к тому, что большое количество ключей не попадет.Этот коэффициент довольно высок, поэтому некоторые люди предложили концепцию последовательного хеширования.
Согласованное хеширование имеет четыре важные характеристики:
- Баланс: некоторые люди также определяют это как баланс, что означает, что результат хеширования может быть максимально распределен по всем узлам, чтобы можно было эффективно использовать ресурсы на каждом узле.
- Монотонность: есть много переводов о монотонности, которые меня озадачивают, и я хочу, чтобы при изменении количества узлов результат хеширования максимально защищал то, что было выделено, от переназначения новому узлу.
- Дисперсия и загрузка: эти два значения на самом деле означают одно и то же, то есть требуется согласованный алгоритм хэширования, чтобы максимально избежать дублирования хэшей ключей.
В кластере Redis встроено 16384 хеш-слота.Когда ключ-значение необходимо поместить в кластер Redis, Redis сначала использует алгоритм crc16 для вычисления результата для ключа, а затем вычисляет оставшуюся часть результата до 16384, так что каждый ключ будет соответствовать хеш-слотам с номерами от 0 до 16383, Redis будет сопоставлять хеш-слоты с разными узлами примерно одинаково в зависимости от количества узлов.
Преимущество использования хеш-слотов заключается в том, что узлы можно легко добавлять или удалять.
- Когда вам нужно добавить узлы, вам нужно всего лишь переместить некоторые хеш-слоты других узлов на новый узел;
- Когда вам нужно удалить узел, вам нужно только переместить хеш-слот на удаленном узле на другие узлы;
- Когда установлены отношения ведущий-ведомый, когда ведомый подключается или повторно подключается к ведущему в первый раз, ведомый отправляет команду синхронизации ведущему;
- После того, как мастер получает команду, он запускает процесс фонового сохранения для сохранения данных, а затем собирает все команды модификации данных. После сохранения фона мастер отправляет данные слейву. Слейв сначала сохраняет данные на диск, а затем загружает их в память. Затем мастер построчно отправляет инструкции по модификации собранных данных слейву. получает его Повторно выполнить инструкцию, тем самым добившись синхронизации данных.
- Ведомый автоматически восстанавливает соединение после потери связи с ведущим. Если ведущее устройство получает запросы на синхронизацию от нескольких ведомых устройств, оно выполняет одно фоновое сохранение для обслуживания всех ведомых устройств.
5.4 Обнаружение сбоя узла
Вот как реализована проверка отказа узла:
- Когда узел отправляет команду PING другому узлу, но целевой узел не может вернуть ответ на команду PING в течение заданного срока, узел, отправляющий команду, помечает целевой узел как PFAIL (возможный сбой).
- Период ожидания ответа от команды PING называется «время ожидания узла» и является настройкой узла.
- Каждый раз, когда узел отправляет команду PING другим узлам, он случайным образом передает три информации об известных ему узлах, одна из которых — отмечен ли узел как PFAIL или FAIL.
- Когда узел получает сообщения от других узлов, он записывает те узлы, которые были отмечены другими узлами как неисправные. Это называется отчетом об отказе.
- Если узел пометил узел как PFAIL, и на основании отчета об отказе, полученного узлом, большинство других главных узлов в кластере также считают, что узел перешел в состояние сбоя, тогда узел отметит состояние этого отказавшего узла. за НЕУДАЧУ.
- Как только узел помечен как FAIL, информация о сбое узла передается всему кластеру, и все узлы, которые получают эту информацию, помечают отказавший узел как FAIL.
Проще говоря, чтобы узел пометил другой узел как недействительный, он должен сначала узнать мнение других узлов и получить согласие большинства главных узлов. Поскольку отчеты об ошибках с истекшим сроком действия удаляются, главный узел должен использовать последний полученный отчет об ошибке в качестве основания для пометки узла как FAIL.
Состояние FAIL узла удаляется в следующих двух случаях:
- Если это подчиненный узел, помеченный как FAIL, то, когда узел вернется в оперативный режим, флаг FAIL будет удален. Нет смысла возвращать подчиненный узел в состояние FAIL, потому что он не обрабатывает слоты, а то, находится ли подчиненный узел в состоянии FAIL, определяет, может ли подчиненный узел быть повышен до главного узла при необходимости.
- Если главный узел помечен как FAIL, после четырехкратного тайм-аута узла плюс десять секунд операция аварийного переключения для слота главного узла не завершена, и главный узел вернулся в оперативный режим, то снимите флаг FAIL для этого узла.
- Во втором случае, если аварийное переключение не завершается успешно и основной узел возвращается в оперативный режим, кластер продолжает использовать старый основной узел, устраняя необходимость во вмешательстве администратора.
5.5 Выбор ведомого узла
Как только главный узел переходит в состояние FAIL, если у главного узла есть один или несколько подчиненных узлов, тогда один из подчиненных узлов будет обновлен до нового главного узла, а другие подчиненные узлы начнут выполнять операции на новом главном узле. копировать
Новый главный узел выбирается всеми подчиненными узлами автономного главного узла.Условия выбора следующие:
- Этот узел является подчиненным узлом автономного главного узла.
- Количество слотов, за обработку которых отвечает автономный мастер, не является пустым.
- Данные подчиненного узла считаются надежными, то есть продолжительность отключения канала репликации между ведущим и подчиненным узлами не может превышать произведения времени ожидания узла, умноженного на константу REDIS_CLUSTER_SLAVE_VALIDITY_MULT.
Если подчиненный узел удовлетворяет всем вышеперечисленным условиям, то подчиненный узел отправит запрос на авторизацию другим главным узлам в кластере, спрашивая их, разрешить ли себе (подчиненному узлу) быть повышенным до нового главного узла.
Главный узел вернет подчиненному узлу авторизацию FAILOVER_AUTH_GRANTED, соглашаясь с требованиями обновления подчиненного узла, если подчиненный узел, отправляющий запрос на авторизацию, удовлетворяет следующим атрибутам:
- Это подчиненный узел, который отправляет запрос на авторизацию, а главный узел, которому он принадлежит, находится в состоянии FAIL.
- Среди всех подчиненных узлов автономного главного узла идентификатор узла этого подчиненного узла является наименьшим в сортировке.
- Ведомый узел находится в нормальном рабочем состоянии: он не помечен как FAIL и не помечен как PFAIL.
Как только подчиненный узел авторизуется большинством главных узлов в течение заданного периода времени, он начинает выполнять следующие операции аварийного переключения:
- Сообщите другим узлам через пакеты PONG (пакет), что этот узел теперь является главным узлом.
- Сообщите другим узлам через пакеты PONG, что этот узел является повышенным ведомым.
- Требование всех хеш-слотов, обрабатываемых автономным мастером.
- Явно рассылайте пакет PONG всем узлам, чтобы ускорить процесс идентификации этого узла другими узлами вместо ожидания пакетов PING/PONG с синхронизацией.
- Все остальные узлы соответствующим образом обновят конфигурацию на основе нового мастера, в частности:
А. Все слоты, занятые новым мастером, обновляются.
б) Все подчиненные узлы автономного главного узла получат флаг PROMOTED и начнут репликацию на новый главный узел.
в) Если главный узел, находящийся в автономном режиме, возвращается в оперативный режим, то он воспринимает флаг PROMOTED и настраивает себя как подчиненный узел текущего главного узла.
В течение жизни кластера, если главный узел с флагом PROMOTED по какой-либо причине становится подчиненным узлом, этот узел теряет свой флаг PROMOTED.
6. Резюме
Кластер Redis обладает такими характеристиками, как высокая доступность, простая миграция и высокая скорость доступа. Он также может использоваться в качестве очереди сообщений и поддерживает режим pub/sub.Конкретные преимущества и недостатки резюмируются следующим образом:
Первое преимущество:
- После того, как главный узел отключится, подчиненный узел будет автоматически повышен до главного узла для предоставления услуг.
- После восстановления узла времени простоя redis он будет автоматически добавлен в кластер и станет подчиненным узлом.
- Динамическое расширение и удаление узлов, выделение слотов для повторного хеширования и распределение данных на основе сегментов значительно снижают затраты на миграцию.Миграция может быть выполнена путем простого переноса сегментов данных с одного узла Redis на другой.
- Redis Cluster использует асинхронную репликацию.
Его недостатки:
- Поскольку репликация Redis использует асинхронный механизм, кластер может потерять команды записи во время автоматического перехода на другой ресурс. Однако Redis выполняет эти две операции (отправку команды recovery клиенту и копирование команды на подчиненный узел) практически одновременно, поэтому на практике окно потери команды очень мало.
- Обычный режим master-slave поддерживает аутентификацию с шифрованием auth.Хотя он относительно слабый, для записи или чтения требуется аутентификация по паролю.Cluster не очень дружелюбен к поддержке пароля.Если для кластера установлен пароль, то и requirepass, и masterauth должны быть ставить, иначе будет master-slave.При переключении будут проблемы с авторизацией, можно имитировать и наблюдать лог.