Как сервера договариваются друг с другом: алгоритм распределённого консенсуса Raft

Распределённый консенсус – один из ключевых терминов дивного мира распределённых систем. Сама по себе тема распределённого консенсуса огромна и сложна, при этом она крайне важна для понимания инженера, работающего в таком окружении.

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

⭐️ Интересные идеи

➡️ Raft работает на основе лога изменений состояния (напоминает Event Sourcing). Всегда есть лидер, который отвечает за управление этим распределённым логом. При нормальной работе лидер всегда один.

➡️ Raft делит время на отрезки произвольной длины, называемые сроками. Срок – это период, в течение которого выбранный лидер исполняет свои обязанности. По окончании срока выборы происходят заново, и лидер может смениться.

➡️ Лидер принимает запросы на запись от клиентов и реплицирует их на фолловеров. Когда большинство фолловеров подтверждают успешное сохранение записи, лидер считает запись закоммиченной и отправляет клиенту сообщение об успешном сохранении. Если фолловер не отвечает, лидер будет повторять попытки записи до бесконечности.

➡️ Благодаря тому, что данные хранятся в виде append-only log, работа алгоритма становится очень надёжной: не возникает конфликтов при изменении записей.

➡️ Писать собственную реализацию Raft не стоит: уже есть готовые библиотеки (например, от HashiCorp). Либо можно воспользоваться базой данных, которая использует Raft под капотом (например, etcd).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи