Организация кластера для хранения распределенной конфигурации на базе Raft алгоритма

Raft-кластер — это распределенная система узлов, использующая алгоритм консенсуса Raft для поддержания согласованного состояния и обеспечения отказоустойчивости.

Основы алгоритма

Raft используется поверх кластера однообразных слабо связных узлов, на каждом из которых работает машина состояний. Raft-алгоритм обеспечивает надежную доставку сигналов на все узлы в заданном порядке. Благодаря чему обеспечивается переход всех машин состояний по одним и тем же последовательностям состояний, и каждый узел гарантированно приходит в согласие с другими узлами.

В Raft-кластере каждый из серверов в каждый момент времени находится в одном из трех состояний:

• leader (мастер) – сервер обрабатывает все клиентские запросы, является источником истины всех данных в логе, поддерживает лог ведомых серверов;
• follower (реплика) – пассивный сервер, который только «слушает» новые записи в лог от мастера и перенаправляет все входящие запросы от клиентов на мастера;
• candidate (кандидат) – специальное состояние сервера, возможное только в момент выборов нового мастера (голосования).

Управление кластером четко разделено на две фазы:

• выборы мастера (голосование);
• репликация (передача данных протокола).

Выборы мастера

Raft предполагает, что на кластере всегда существует явно выделенный мастер. Только мастер отправляет новые записи на другие узлы (реплики) кластера. Остальные узлы следуют за мастером и не взаимодействуют между собой (за исключением фазы голосования). Если внешний клиент подключается к кластеру через обычный узел, то все его запросы перенаправляются мастеру и только оттуда приходят на остальные узлы.

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

Процедура голосования повторяется, пока не будет выбран мастер. Как только мастер определен, все узлы узнают о нем и начинается процесс репликации данных протокола.

Репликация протокола

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