Изначально планировался один небольшой пост с примером создания 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.
Ссылки по теме
- Redis community
- Redis replication
- Redis cluster tutorial
- Redis Cluster Specification
- Intro to Redis Cluster Sharding
- How to Setup Redis Cluster from Source
- Redis Replication vs Sharding
- Redis Cluster vs Redis Replication
- Redis Sentinel & Redis Cluster – what?
- What Redis deployment do you need?
