Raft — это алгоритм консенсуса, предназначенный для управления реплицируемым логом в распределенных системах.
Объясняя простыми словами: это протокол, который помогает группе серверов договориться между собой об общем состоянии: выбрать главный сервер и обеспечить консистентность данных между узлами, даже если некоторые из них выйдут из строя.
Давай поговорим про него подробнее.
Как работает
Raft консенсус применяется только к кластеру как целому, чтобы обеспечить отказоустойчивость и единое мнение между разными физическими/виртуальными машинами.
Внутри одной ноды синхронизация решается локальными примитивами (мьютексы, атомики, каналы).
1. Роли
В кластере (например, из 3 или 5 серверов) в каждый момент времени есть три типа граждан:
- Лидер — только он принимает запросы от клиентов и командует остальными.
- Кандидат — временная роль. Сервер, который хочет стать лидером.
- Фолловер — подчиненный. Просто слушает лидера и копирует у него данные.
2. Процесс работы
Шаг А. Выборы лидера (когда система стартует или лидер умер)
- У всех нод (фолловеров) есть свой тайм-аута на определение является ли он лидером.
- Если любой фолловер не получает мессаджа лидера (heartbeat) до истечения его тайм-аута, он решает — «Лидер мертв, теперь я попробую им быть».
Он отправляет мессадж всем нодам — «Я здесьвластьлидер» и становится Кандидатом просят у других нод разрешение.
- Если другие ноды не против — они отвечают ему подтвеждением и эта нода становится лидером а остальные фоловерами.
(Если кандидатов на лидерство > 1 — это объясняется по ссылкам интерактивной работы алгоритма и в видео ниже) - После этого консенсус достигнут и лидер нода начинает отправлять heartbeat пакет через интервал чтобы сказать остальным нодам что
— Я жив
Если этого не произойдет и мастер нода у нас прилегла — начинаем с п.1
Шаг Б. Работа с данными (репликация лога)
- Клиент приходит к Лидеру и говорит
— Запиши значение «Вася = 500». - Лидер не спешит отвечать.
Он записывает это к себе в черновик и командуем всем фолловерам
— Ребята, срочно запишите у себя «Вася = 500». - Фолловеры записывают и шлют подтверждение (ACK) Лидеру.
- Лидер считает голоса.
Как только пришло подтверждение от большинства (например, 2 из 3), Лидер фиксирует запись, применяет её к своей базе и отвечает Клиенту
— Готово, данные сохранены. - Оставшийся третий фолловер (если тормозил или отвалился) догонит потом сам, получив данные от лидера повторно.
Количество нод кворума необходимых для подтверждения консенсуса считается по формуле N/2+1.
С интерактивной визуализацией алгоритма можете ознакомиться на сайтах:
— пример 1
— пример 2
Проблемы которые решает Raft консенсус
- Выбор лидера.
В Raft всегда есть один главный узел (лидер), который управляет репликацией логов.
Если лидер пропадает, алгоритм автоматически и быстро выбирает нового. - Обеспечение high availability.
Система остается работоспособной до тех пор, пока доступно большинство узлов —N/2+1(кворум).
Например, в кластере из 5 серверов система продолжит работу, даже если 2 из них упадут. - Consistency.
Алгоритм гарантирует, что все узлы применят одни и те же команды в одном и том же порядке. Это исключает ситуацию, когда разные части системы выдают неконсистентную информацию. - Линеаризуемость.
Это высшая форма гарантии согласованности данных (между нодами) с точки зрения клиента.
Когда использовать
Выбор Raft — это осознанный приоритет Strong Consistency и Total Ordering над предельной скоростью. Классическая CP система из CAP теоремы.
Использование Raft — это архитектурный контракт
Мы соглашаемся на накладные расходы по сети и диску, чтобы гарантировать линеаризуемость событий и исключить Split-brain.
Его стоит внедрять там, где порядок операций и целостность данных критичнее времени отклика, а цена ошибки при автоматическом восстановлении кластера — это финансовые потери или порча бизнес-логики.
- Банковские транзакции.
Здесь Raft (strong consistency) жизненно необходим.
Нельзя, чтобы при переводе денег на одном сервере баланс был 100, а на другом 0. - Координация сервисов (etcd, Consul, Zookeeper).
Нельзя, чтобы половина сервисов думала, что главный сервер — А, а другая половина — что главный — Б.
Это приведет к катастрофе (split-brain).
Когда НЕ стоит использовать
- Высокая частота обновлений данных.
Если у нас миллионы мелких записей в секунду (лайки, метрики, логи), Raft захлебнется на этапе сетевых подтверждений и синхронных записей на диск. - Глобально распределенные системы с большими задержками.
Если узлы находятся в разных частях света (США, Европа, Азия), ожидание кворума превратит каждый запрос в секундное ожидание. - Кэширование.
Для кэша (Redis, Memcached) важнее скорость.
Если данные в кэше пропадут или временно устареют — это не критично.
Инстументы использующие Raft
Распределенные базы данных NewSQL и NoSQL:
- CockroachDB
- YugabyteDB
Queues:
- RabbitMQ — в Quorum Queues
Хранилища конфигураций и Service Discovery:
- etcd
- Consul (HashiCorp) — для обнаружения сервисов и хранения конфигураций.
Почему синхронно не писать на реплики в БД?
1. Скорость самого медленного узла
Представьте, что у вас 3 сервера в разных дата-центрах: в Москве, во Владивостоке и в Нью-Йорке.
- Клиент пишет данные.
- Лидер отправляет команду всем троим.
- Сервер в Москве ответил через 10 мс.
- Сервер в Нью-Йорке ответил через 150 мс.
- Сервер во Владивостоке… потерял пакет, переспросил, ответил через 350 мс.
При синхронной записи на все реплики клиент будет ждать ответа 350 мс.
Система будет тормозить ровно настолько, насколько тормозит самый худший сервер.
В распределенной системе это может быть катастрофой.
2. Все или ничего
Что произойдет, если сервер во Владивостоке упал?
При синхронной записи на все реплики — ничего не выйдет.
Вы не сможете записать данные, потому что не можете записать их на все.
Один упавший сервер парализует всю систему на запись.
Это очень плохо для high-availability.
3. Раздвоение личности
Даже если мы пишем на все реплики, кто решает, какой сервер главный?
Представим сценарий с сетью:
У нас есть 3 сервера: A, B, C.
Между серверами A и (B, C) порвалась сеть.
- Сервер А думает: Я жив, но B и C не отвечают. Буду писать сам себе.
- Серверы B и C думают: А не отвечает. Давай выберем нового лидера?
Если мы просто пишем на все реплики синхронно, то в момент разрыва сети у нас может возникнуть ситуация, когда две части кластера начнут принимать данные независимо.
Потом сеть починят, и что делать с этими двумя разными наборами данных? Как их смержить?
Итог
Выбор Raft — это осознанный приоритет Strong Consistency и Total Ordering над предельной скоростью.
Это архитектурный контракт — мы согласны на накладные расходы по сети и диску, чтобы гарантировать линеаризуемость событий и исключить Split-brain.
Он был создан как более понятная альтернатива сложному алгоритму Paxos алгоритм.
Главная цель разработчиков Raft — понятность.
Raft стоит внедрять там, где порядок операций и целостность данных критичнее времени отклика, а цена ошибки при автоматическом восстановлении кластера — это финансовые потери или порча бизнес-логики.
Telegram