В Redis 3 должна появиться возможность использовать несколько Redis-нод как кластер. О кластере говорили давно, примерно тогда же пытались сделать, но вскоре поняли, что с разбегу сделать его не получится — надо решить перед этим ряд проблем.
И вот уже Redis 3 rc-3 — документации особо нет, но есть пара paper’ов, описывающих виденье разработчиков.
Что сулит кластер:
- Автоматическое разделение данных между многими нодами.
- Успешное завершение операций даже при условии, если часть нод упала или недоступна.
Каждая нода будет сидеть на 2-х портах — один для общения с клиентом и ещё один для перегонки данных между нодами. Отличаться они будут ровно на 10000. То есть, если мы используем 6379-ой порт для общения с клиентом, 16379-ой будет использоваться для общения в кластере по бинарному протоколу.
Шардинг не последовательный, вместо этого используются хеш-слоты. 16384 слотов, хеш-слот получается из ключа простейшим способом: берём CRC16, делим по модулю 16384. Дальше хеш-слот отображается на одну из нод. По-сути в данном случае хеш-слот = виртуальный шард. Их можно раскидать на ноды, потом изменить физическую конфигурацию кластера — решардинг без downtime => profit!
Для поддержки доступности используются репликации каждой ноды. То есть, если у нас кластер из 3-х нод: A, B, C — по ним разделены хеш-слоты (0 — 5500, 5501 — 11000, 11001 — 16383). Каждая нода — master, к ней стоит репликой slave: A1, B1, C1. Если мастеры вылетают — кластер начинает работать со слейвами (прошу прощения за «смешение английского с нижегородским»). Если и последние отсутствуют — мы остаёмся без части данных, лежащих на них.
Во время, когда мастер становится недоступен, запускается механизм голосований среди реплик на должность мастера. Не сразу — через node timeout, который конфигурируется. Если после голосования бывший мастер становится доступен, а реплика была признана большинством как новый мастер, старый слагает с себя полномочия и резко забывает всё, что успел узнать за время разрыва сети. Так могут теряться данные. Ещё один пример того, что механизм голосований может работать во вред :)
Redis кластер не даёт строгой консистентности. Только weak/lazy-consistency. В некоторых случаях он может «забыть» записать данные. За это мы получаем асинхронность: пишем в B, сразу получаем ответ, идём дальше. А B начинает рассылать на свои реплики изменения. B может упасть до того, как пошлёт репликам обновления. Тогда реплика займёт его место, не зная о том, что что-то изменилось. В общем-то, очередная иллюстрация CAP-«теоремы».
В планах добавление синхронной записи (опционально) для ситуаций, когда потеря недопустима.
Собственно как-то так будет выглядеть Redis-кластер. Остаётся дождаться «замороженной» версии для production и начать использовать — выглядит вполне себе приятно.