Redis Cluster

06/12/2021

По долгу службы надо было разобраться что из себя представляет Redis Sentinel кластер. Ну а я как всегда начал смотреть на тему чуть шире.

Зачем нужен кластер в принципе? Для любой БД рано или поздно встает следующий список вопросов:

• Масштабирование размера хранилища
• Ускорение операций чтения/записи
• Доступность сервиса в случае отказа

Кластеризация Redis предоставляет ответы на эти вопросы в рамках разных подходов. Давайте посмотрим, что нам предлагается.

Replication (mirroring)

Самым простым случаем является классический ведущий-ведомые (мастер-слейв) вариант кластера, который ускоряет операции чтения данных.

Мастер реплицирует (дуплицирует) данные в слейвы тем самым разгружает с себя чтения. Обычно писать можно только в мастер, а читать из мастера и слейвов.

Sharding (partitioning)

При шардировании данные разделяются на отдельные непересекающиеся наборы, каждый из которых располагается на одельном узле (ноде). Без этого мы ограничены объемом памяти, ЦПУ и пропускной способностью сетевой карты, которыми располагает один компьютер.

Таким образом операции записи будут ускорятся за счёт работы только с частью общего набора данных.

Минутка ликбеза – шардирование != партиционирование. Шардирование – это именно физическое разделение данных непосредственно по отдельным узлам, путь к каждому из которых опредляется заранее заданным ключем (ID компании-клиента, имена пользователей от A до D). Партицирование – подразумевает логическое разделение данных по какому-либо критерию (временной интервал). Например, одна большая таблица БД может быть разбита на несколько меньших таблиц, каждая из которых будет представлять 1 год операционной деятельности компании. И совсем не обязательно располагать каждую таблицу на отдельной ноде. Однако, ничего не мешает использовать оба подхода разбиения данных вместе. В контексте же Redis вроде как это взаимозаменяемые термины.

Sentinel

По сути Sentinel является распределенным мониторингом мастер ноды в Redis кластере. Клиент может писать только в мастер, значит ему надо точно знать, кто в данный момент является таковым в рамках кластера. Вроде бы ничего сложного – просто укажи в конфигурации клиента хост/порт мастер ноды и дело с концом. Но что если текущий мастер приказал долго жить? Вот как раз для этого случая Sentinel делает автоматическое аварийное переключение одного из слейвов в новый мастер и соответственно оповещает об этом клиентов.

Другими словами Sentinel – это облегчённый вариант отказоустойчивого классического кластера для тех, кто не осилил полноценный мульти-мастер кластер. Как и в большинстве других распределнных систем нужно разворачивать миниму 3 экземпляра для кворума. Чаще всего Sentinel демоны деплоятся на тех же узлах, что и сами Redis серверы.

Один из экзмепляров Sentinel может выступать в роли мастера (голубенький на диаграмке). Не стоит путать его с Redis мастер сервером. Sentinel мастер роль лишь дает приоритет при выборе нового Redis мастера и ничего более.

Multi-Master

Этот зверь возмет на себя все тяготы нелегкой жизни распределенной БД от репликации до аварийного переключения. Однако, для работы с таким кластером Redis клиент должен поддерживать соответствущий уровень общения (Ruby клиент умеет).

Минимальные требования для кворума – 3 мастера + 3 слейва.