Redis

Это даже не совсем БД - как утверждают разработчики это скорее хранилище различных типов данных (причём в основном в памяти). Поддерживает множество различных типов и структур данных, а так же может использоваться не только как хранилище данных, но и как брокер сообщений (можно, например, подписаться и получать уведомления при изменениях)Находит применение в различных приложениях - организация очередей, чаты, шина даннфх между приложениями и многое другое.

Репликация

На сколько плохо я вычитал интернеты у Redis есть два типа репликации - хитрая встроенная, котороая настраивается странной пачкой скриптов и с помощью sentinel (где последний управляет процессом ремастеринга)

Sentinel

Небольшое приложение, которое занимается распределением ролей в кластере и, соответственно, переключением их. На этом, пожалуй, его полномочия и всё. Имеет интересную особенность - динамические конфиги, за счёт чего при попытках занести его под какую-либо SCM вызывает невероятное количество боли и страданий. (Единственно верное решение, которое я смог придумать - использовать SCM только в момент бутстрапа, дальше ручник и надежды на sentinel)

Собственно настройка кластера проста и не замысловата:

1. Ставим нечётное количество серверов в кластер
2. Самостоятельно выбираем мастер и через redis-cli даём ему коману SLAVEOF NO ONE
3. На остальных нодах в конфиге прописываем строчку slaveof <ip master> и рестартуем redis
4. На master ноде выполняем info replication и смотрим, что слейвы подцепились
5. Если нет - идём на слейв и выполняем slaveof <ip master> <port master>
6. Повторяем пункты с 4 пл 6, пока все ноды не соберутся в кластер

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

sentinel.conf
port 26379
dir "/"
maxclients 4064
sentinel known-slave mymaster <ip master> <port master> <count for quorum>

Раскладываем его по всем хостам и запускаем sentinel, начиная с мастера.

Если всё пройдёт успешно - в логах sentinel появится информация о том, что достигнут кворум и выбран мастер. Если sentinel выберет не тот мастер, который мы ему подсунули - он сам произведёт ремастеринг в redis и перезапишет свой конфиг. (Но не конфиг redis, с этим надо быть внимательным) Иногда бывает, что sentinel не может достичь кворума или у него несколько мастеров - для исправления нужно в конфигах всех сентинелов выставить один и тот же мастер.

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