Redis: репликация, часть 1 – обзор. Replication vs Sharding. Sentinel vs Cluster. Топология Redis.

Автор: | 29/03/2019
 

Изначально планировался один небольшой пост с примером создания Redis-репликации, но по мере углубления в детали – захотелось описать всё больше и больше, а потому разбил материал на две части.

В этой, обзорной – общие сведения, разница между различными типами хранения данных в Redis, примеры топологии.

Достаточно кратко, но со ссылками на детальную документацию, плюс ссылки на полезные материалы в конце поста.

Во второй – примеры создания и настройки Master-Slave репликации и использования Redis Sentinel.

В третьей – работа с Redis Sentinel из Python.

В четвёртой – написание Ansible роли для автоматизации развёртывания репликации и Sentinel.

Redis Replication vs Sharding

Redis поддерживает два типа распределения данных – replication (mirroring, дублирование данных) и sharding (partitioning, сегментирование). При этом в кластере (см. ниже) возможно использование обоих типов одновременно.

Replication

Представляет собой копирование всех данных между всеми узлами кластера, что позволяет выполнять запросы к данным с двух или более нод, плюс данные хранятся на всех нодах, таким образом обеспечивая надёжность данных (high availability).

При таком подходе увеличивается скорость выполнения read-операций.

См. Replication и Redis Cluster master-slave model.

Sharding

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

При таком подходе увеличивается скорость выполнения write-операций.

См. Partitioning: how to split data among multiple Redis instances и Redis Cluster data sharding.

Redis Sentinel vs Redis Cluster

Redis Sentinel

Был добавлен в Redis v.2.4, и является сервисом мониторинга состояния мастер и слейв нод. Умеет отправлять уведомления о событиях, выполнять переключение между мастером и слейвом, если мастер вышел из строя и т.д. Имеет смысл в использовании, если используется “голая” мастер-слейв репликация без полноценного кластера.

Работает как отдельный демон используя либо отдельный исполняемый файл sentinel, либо redis-server в режиме sentinel.

Выполняет настройку нод в случае выхода из строя мастера: определяет, какая из нод станет новым мастером, выполняет их перенастройку на ходу.

Требует как минимум трёх работающих инстансов для достижения кворума при определении статуса Redis-мастера или слейв-нод.

Redis Cluster

Был добавлен в Redis v.3.0, и является полноценным native решением для создания и управления кластером с сегментацией и репликаций данных. Выполняет задачи управления нодами, репликации, синхронизации данных, обеспечением доступа к ним в случае выхода из строя одного или более мастеров.

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

См. Redis Sentinel & Redis Cluster – what? и Redis Sentinel Documentation.

Топология Redis

Один Redis-инстанс

Самый классический случай.

Простой в запуске и настройке.

Ограничен ресурсами хоста, на котором запущен – его процессором и памятью.

В случае выхода из строя хоста или самого сервера Redis – разумеется, упадут все зависящие от него службы, т.е. никакого обеспечения надёжности нет.

Master-slave репликация

Один мастер, к которому подключены несколько слейвов, на которые выполняется полная репликация всех данных.

Данные обновляются на мастере, после чего он отправляет информацию об обновлениях на слейвы.

Слейвы общаются только  с мастером (но могут иметь собственные слейвы).

Слейвы являются read-only нодами – никаких изменений на них не выполняется (если явно не задано другое, см. во второй части).

В случае выхода из строя одной из нод – все данные останутся доступными с других улов.

Прост в настройке, но операции записи ограничены доступными мастеру ресурсами.

В случае выхода из строя мастера – требует ручного вмешательства для переопределения нового мастера из одного из слейвов, кроме того – клиенты должны точно знать на какую ноду выполнять запросы чтения и записи.

Redis Sentinel

Уже описывался выше, но ещё несколько слов.

Как и в случае с репликацицей Redis – имеет одну Master Sentinel ноду, которая имеет приоритет при принятии решения о том, какую ноду Redis использовать в роли Master.

Т.е, в случае с одним Мастером Redis и двумя слейвами, и если Master Sentinel работает на том же хосте, где Мастер Redis-а, и этот хост умирает – Sentinel определяет свой новый мастер-инстанс, затем два оставшихся Sentinel-инстанса принимают решение о том, какой из оставшихся двух Redis-нод станет новым мастером. При этом у мастер-инстанса Sentinel будет приоритет при принятии решения.

Стоит учитывать, что не все клиенты умеют работать с моделью Redis Sentinel, список клиентов – тут>>>.

Redis Cluster

И самый полнофункциональный вариант – Redis Cluster.

Несколько мастер-инстансов, у каждого один или более слейвов (до 1000).

Выполняет все задачи по шардингу, репликации, failover, синхронизации данных.

Требует как минимум 6 нод Reedis-а: три для мастеров, и три для слейвов.

Умеет перенаправлять запросы от клиентов на нужный мастер или слейв – но это требует поддержки кластера самими клиентами Redis.

Ссылки по теме