Хотя Redis Sentinel решает проблему автоматического аварийного переключения Redis, он по-прежнему использует одну машину. Когда объем параллелизма высок, будут возникать узкие места, такие как память, параллелизм, хранилище и т. д., что требует использования распределенной архитектуры Redis для достижения балансировки нагрузки.
Распределенное решение Redis
Redis Sharding
Можно сказать, что Redis Sharding — это метод кластеризации нескольких экземпляров Redis, широко используемый в отрасли до появления Redis Cluster. Основная идея заключается в использовании хеш-алгоритма для хэширования ключа данных Redis, и с помощью хеш-функции определенный ключ будет сопоставлен с конкретным узлом Redis. Таким образом, клиент знает, на каком узле Redis работать с данными. Это реализация разделения на стороне клиента. Разделение клиента реализуется путем размещения логики разделения на клиенте Redis и перенаправления доступа к ключу соответствующему экземпляру Redis с помощью правил маршрутизации, предварительно определенных клиентом Redis.
- преимущество: Вся логика управляема, не зависит от стороннего распределенного промежуточного ПО, конфигурация проста, нет привязки к Redis на стороне сервера.
- недостаток: клиент не может динамически добавлять или удалять сервисные узлы, клиент должен самостоятельно поддерживать логику распределения, а ремонтопригодность оставляет желать лучшего.
Codis
Codis — это распределенное решение Redis (с открытым исходным кодом бывшей команды Wandoujia). Для приложений верхнего уровня нет очевидной разницы между подключением Codis Proxy и подключением к собственному серверу Redis (список неподдерживаемых команд). Приложения верхнего уровня могут использовать он же используется как одномашинный Redis.Нижний уровень Codis будет обрабатывать пересылку запросов, непрерывную миграцию данных и т. д. Все следующие вещи прозрачны для фронт-клиента.Можно просто считать, что обратное соединение — это бесконечная память, сервис Redis. Это прокси-решение на основе промежуточного программного обеспечения.Для достижения высокой доступности Codis вам необходимо развернуть несколько экземпляров Codis.
По умолчанию Codis делит все ключи на слоты 1024. Сначала он выполняет операцию crc32 над ключом, переданным от клиента, для вычисления хеш-значения, а затем модулирует целое значение после хэша до целого числа 1024 для получения остатка. слот, соответствующий ключу. Каждый слот однозначно сопоставляется с одним из следующих экземпляров Redis, и Codis поддерживает отношения сопоставления между слотами и экземплярами Redis в памяти. Отношение слотов между несколькими экземплярами Codis должно поддерживаться Zookeeper, что увеличивает нагрузку на эксплуатацию и обслуживание.
- преимущество: Реализованы высокая доступность, сегментация данных и автоматическая балансировка прокси-сервера верхнего уровня и базового Redis, предоставляется интерфейс командной строки и RESTful API, предоставляется интерфейс мониторинга и управления, а узлы Redis могут динамически добавляться и удален.
- недостаток: архитектура развертывания и конфигурация сложны, что увеличивает стоимость эксплуатации и обслуживания. Транзакции и некоторые команды не поддерживаются, а добавление прокси-слоя приводит к снижению производительности. Поскольку это неофициальное кластерное решение, оно всегда будет медленнее официального Redis, и синхронизация новых функций с официальным займет много времени.
Redis Cluster
Redis 3 официально запустил официальную кластерную технологию, которая решила проблему совместных сервисов нескольких экземпляров Redis. Можно сказать, что Redis Cluster является воплощением технологии сегментирования на стороне сервера, то есть значение ключа разумно выделяется для каждого сегмента экземпляра в соответствии с определенным алгоритмом, и каждый узел экземпляра координирует и взаимодействует для совместного выполнения согласованных внешних услуг. Однако принцип реализации отличается от клиентского сегментирования: кластер Redis вводит слоты (аналогично Codis, но кластер делит 16384 слота), сопоставляет все данные со слотами, а затем каждый узел Redis управляет частью слотов.
- преимущество: нет центрального узла (все узлы Redis являются одноранговыми узлами, а данные синхронизации используют протокол Gossip), данные распределяются по нескольким экземплярам Redis в соответствии с хранилищем слотов, а емкость узла можно плавно увеличивать/уменьшать. изменений узлов, динамически изменяться должен только тот слот, за который отвечает узел, что прозрачно для клиента. Нет необходимости полагаться на промежуточное ПО, а затраты на эксплуатацию и обслуживание низкие.
- недостаток: сильная зависимость от инструментов Redis-trib, отсутствие мониторинга и управления, медленное обнаружение отказоустойчивых узлов и определенная задержка в распространении сообщений протокола Gossip для окончательной согласованности.
Правила разделения данных
Чтобы разделить весь набор данных на несколько узлов и позволить каждому узлу отвечать за часть данных, необходимо использовать правила разделения данных. Обычно используемые правила секционирования — хеш-секционирование и последовательное секционирование.
- хэш-разделДля него характерна хорошая дисперсия, а распределение данных не имеет никакого отношения к бизнесу, но к ним нельзя обращаться последовательно.
- последовательный разделЕго характеристики заключаются в том, что степень дисперсии легко изменить, а распределение данных связано с бизнесом, но к ним можно получить последовательный доступ (в основном используется в базе данных для анализа больших данных).
Redis Cluster принимает правила разбиения хэшей, и существует несколько часто используемых правил разбиения хэшей: разбиение фиксированного хэша, последовательное разбиение хеширования и разбиение хеширования виртуальных слотов.
Фиксированный хеш-раздел
Используйте хеш-функцию, чтобы вычислить значение хэша в соответствии с определенным полем (ключ используется в Redis), а затем возьмите модуль в соответствии с количеством узлов N, чтобы решить, какой узел сопоставить данные. Преимущество этого метода в том, что установка и реализация правил очень просты, а недостаток в том, что расширение или сжатие узлов потребует переноса большого количества данных.
Согласованное разбиение хэша
Консистентное хеширование может очень хорошо решить проблему стабильности.Все узлы хранения могут быть организованы в сквозное хеш-кольцо (размер кольца 2^32), а ключ будет находить ближайший по часовой стрелке после вычисления хеша. узлы хранения для хранения данных. При добавлении или уменьшении узлов затрагивается только следующий узел по часовой стрелке от узла в хеш-кольце.
Когда кластер необходимо расширить, это затронет только следующий узел по часовой стрелке на кольце (это снизит нагрузку на этот узел). Как показано ниже:
Вновь добавленный узел 5 разделяет часть нагрузки с узлом 4, а данные в ключе между узлами 1 и 5 будут перенесены на узел 5 (если он используется в качестве кеша, он будет недействителен напрямую), но это не влияет на другие узлы. узлы.
Когда кластер необходимо уменьшить, уменьшение одного узла повлияет только на следующий узел по часовой стрелке (этот узел возьмет на себя всю нагрузку удаленного узла).
Если node1 удален, то все данные перед node1 будут перенесены в node5 (если кеш напрямую недействителен), node5 возьмет на себя всю нагрузку до node1. Но это по-прежнему не влияет на другие узлы в кластере.
Из вышеизложенного можно сделать вывод, что правило согласованного хеш-раздела не может достичь цели балансировки нагрузки, когда кластер расширяется или уменьшается (если только он не удваивается или не уменьшается вдвое каждый раз), поэтому обычно распределенные системы будут использовать виртуальные узлы (виртуальные узлы). слоты) Улучшения согласованного хеширования.
хеш-раздел виртуального слота
Раздел виртуальных слотов разумно использует хеш-пространство и использует хорошо распределенный хеш-алгоритм (Redis использует алгоритм CRC16) для отображения всех данных в набор целых чисел с фиксированным диапазоном, а целые числа определяются как слоты. Этот диапазон, как правило, намного больше, чем количество узлов. Например, диапазон слотов Redis Cluster составляет от 0 до 16383. Слоты являются базовой единицей управления данными и миграции в кластере.Каждый узел отвечает за определенное количество слотов.Сначала ключи сопоставляются со слотами через хеш-функцию, а затем данные сохраняются в узле, соответствующем слот. Это разделяет связь между узлами и ключами данных (ключи напрямую не сопоставляются с узлами, а со слотами), упрощая расширение и сжатие узлов.
Узлы можно легко добавлять и удалять с помощью секционирования хэшей виртуальных слотов. Если я хочу добавить новый узел Node4, мне просто нужно переместить несколько хеш-слотов с узлов Node1, Node2, Node3 на новый узел Node4. Точно так же, если я хочу удалить узел Node1 из кластера, мне просто нужно переместить хэш-слот, за который отвечает Node1, на Node2 и Node3. Когда все слоты на узле Node1 удалены, их можно полностью удалить из кластера.
Поскольку перемещение хеш-слота с одного узла на другой не требует простоя, добавление и удаление узлов или изменение хеш-слотов, удерживаемых узлом, не требует простоя, что обеспечивает высокую доступность кластера.
протокол сплетен
В распределенном хранилище должен быть предусмотрен механизм поддержки метаданных узла.Метаданные относятся к тому, за какие данные отвечает узел (в Redis — за какие слоты отвечают) и к состоянию узла. Обычно используемые методы обслуживания метаданных — централизованные и P2P. Redis Cluster использует протокол P2P Gossip.
Функция этого протокола такая же, как следует из его названия. Его очень легко понять. Его методы на самом деле очень распространены в нашей повседневной жизни, такие как распространение компьютерных вирусов, лесные пожары, пролиферация клеток и распространение инфекционных заболеваний. .
процесс коммуникации
Каждый узел в кластере откроет отдельный TCP-канал для связи между узлами (номер порта равен порту узла плюс 10000).
Когда узел обновляет состояние (присоединение нового узла, сбой узла, изменение роли master-slave, изменение информации о слоте и т. д.), узел случайным образом распространяет сообщение на несколько окружающих узлов, а узел, получивший сообщение, повторяет это. процесса и, наконец, кластера. Все узлы в кластере получат это сообщение для достижения конечной согласованности состояния кластера.
Преимущество
-
Масштабируемость: сеть может допускать произвольное увеличение и уменьшение количества узлов, и состояние вновь добавленных узлов в конечном итоге будет соответствовать состоянию других узлов.
-
Отказоустойчивость: Простой и перезапуск любого узла в сети не повлияют на распространение сообщений Gossip.Протокол Gossip обладает естественными характеристиками отказоустойчивости распределенных систем.
-
децентрализация: протокол Gossip не требует никакого центрального узла, все узлы могут быть одноранговыми, любому узлу не нужно знать весь статус сети, пока сеть подключена, любой узел может распространить сообщение на весь сеть.
-
окончательная согласованность: протокол Gossip реализует экспоненциальное быстрое распространение информации (logN), поэтому, когда необходимо распространить новую информацию, сообщение может быть быстро отправлено на глобальный узел, и все узлы могут получить самые свежие данные в течение ограниченного времени.
дефект
-
задержка сообщения: в протоколе Gossip узлы будут случайным образом отправлять сообщения только нескольким узлам, и сообщения в конечном итоге достигнут всей сети через несколько раундов распространения, поэтому использование протокола Gossip приведет к неизбежным задержкам сообщений. Он не подходит для использования в сценариях с высокими требованиями к реальному времени.
-
избыточность сообщений: протокол Gossip предусматривает, что узел будет периодически случайным образом выбирать окружающие узлы для отправки сообщений, и узел, который получает сообщение, также будет повторять этот шаг, поэтому неизбежно, что сообщение будет повторно отправлено одному и тому же узлу, в результате чего сообщение избыточность, и в то же время это также увеличивает нагрузку на узел, который получает сообщение. Более того, поскольку оно отправляется периодически, даже узел, получивший сообщение, будет неоднократно получать повторяющиеся сообщения, что увеличивает избыточность сообщения.