Thank you for reading this post, don't forget to subscribe!
Redis Replication vs Sharding
Redis поддерживает два типа распределения данных — replication (mirroring, дублирование данных) и sharding (partitioning, сегментирование). При этом в кластере (см. ниже) возможно использование обоих типов одновременно.
Replication
Представляет собой копирование всех данных между всеми узлами кластера, что позволяет выполнять запросы к данным с двух или более нод, плюс данные хранятся на всех нодах, таким образом обеспечивая надёжность данных (high availability).
При таком подходе увеличивается скорость выполнения read-операций.
Sharding
При использовании сегментирования — данные разбиваются на несколько частей, что улучшает производительность каждой отдельной ноды, т.к. она не хранит и не отвечает за все данные кластера.
При таком подходе увеличивается скорость выполнения write-операций.
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
Один Redis-инстанс
Самый классический случай.
Простой в запуске и настройке.
Ограничен ресурсами хоста, на котором запущен — его процессором и памятью.
В случае выхода из строя хоста или самого сервера Redis — разумеется, упадут все зависящие от него службы, т.е. никакого обеспечения надёжности нет.
Master-slave репликация
Один мастер, к которому подключены несколько слейвов, на которые выполняется полная репликация всех данных.
Данные обновляются на мастере, после чего он отправляет информацию об обновлениях на слейвы.
Слейвы общаются только с мастером (но могут иметь собственные слейвы).
Слейвы являются read-only нодами — никаких изменений на них не выполняется (если явно не задано другое,)
В случае выхода из строя одной из нод — все данные останутся доступными с других улов.
Прост в настройке, но операции записи ограничены доступными мастеру ресурсами.
В случае выхода из строя мастера — требует ручного вмешательства для переопределения нового мастера из одного из слейвов, кроме того — клиенты должны точно знать на какую ноду выполнять запросы чтения и записи.
Redis Sentinel
Уже описывался выше, но ещё несколько слов.
Как и в случае с репликацицей Redis — имеет одну Master Sentinel ноду, которая имеет приоритет при принятии решения о том, какую ноду Redis использовать в роли Master.
Т.е, в случае с одним Мастером Redis и двумя слейвами, и если Master Sentinel работает на том же хосте, где Мастер Redis-а, и этот хост умирает — Sentinel определяет свой новый мастер-инстанс, затем два оставшихся Sentinel-инстанса принимают решение о том, какой из оставшихся двух Redis-нод станет новым мастером. При этом у мастер-инстанса Sentinel будет приоритет при принятии решения.
Стоит учитывать, что не все клиенты умеют работать с моделью Redis Sentinel, список клиентов — тут>>> https://redis.io/clients .
Redis Cluster
И самый полнофункциональный вариант — Redis Cluster.
Несколько мастер-инстансов, у каждого один или более слейвов (до 1000).
Выполняет все задачи по шардингу, репликации, failover, синхронизации данных.
Требует как минимум 6 нод Reedis-а: три для мастеров, и три для слейвов.
Умеет перенаправлять запросы от клиентов на нужный мастер или слейв — но это требует поддержки кластера самими клиентами Redis.