Как я практически использую алгоритм Рафта
В документе Raft они упоминали, что все взаимодействие с клиентом происходит с лидерским узлом. Чего я не понимаю, так это того, что лидер постоянно меняется. Допустим, мой кластер находится за балансировщиком нагрузки. Как мне сообщить балансировщику нагрузки, что лидер сменился? Или, если я прав, балансировщик нагрузки может отправлять запрос клиента любому узлу (подписчику или руководителю), и ответственность за отправку запроса руководителю возлагается на узел подписчика?
2 ответа
На самом деле это можно сделать двумя способами: либо балансировщику нагрузки необходимо понять, где находится лидер, либо подписчики могут прокси-запросы к руководителю.
Нет ничего плохого в том, чтобы передавать запросы клиентов руководителю через подписчика, и на самом деле это может принести значительные выгоды. Многие реализации Raft позволяют клиентам читать от последователей, поддерживая последовательную согласованность. Это все еще можно безопасно сделать с помощью балансировщика нагрузки, отправляющего запросы на произвольные узлы, если клиент отслеживает последний индекс, который он видел, и отправляет его с каждым запросом, чтобы убедиться, что он не видит состояние назад во времени. Я не буду писать полный алгоритм здесь, но это описано в диссертации Рафта, с которой вам следует ознакомиться.
Но использование балансировщика нагрузки таким способом может стать небезопасным в некоторых случаях. Если клиентам разрешено отправлять несколько одновременных запросов, балансировщик нагрузки может направить эти запросы через разные узлы, и они могут прийти к лидеру не по порядку. Это можно объяснить, прикрепив порядковый номер к клиентским запросам и переупорядочив запросы к руководителю. Но для этого реализация должна включать сеансы, чтобы лидер мог отслеживать состояние каждого клиента.
Однако, как правило, клиенты Raft подключаются к определенным узлам и остаются подключенными к ним как можно дольше, чтобы сократить издержки на поддержание согласованности при переключении серверов. Если реализация поддерживает чтение от последователей, переключение серверов может все еще быть дорогостоящим, поскольку серверам приходится ждать, пока состояние не догонит их, чтобы поддерживать последовательную согласованность.
После окончания голосования у вас будет лидер (новый или старый). Ответственность за то, чтобы все узлы в сети регулярно отправляли тактовые импульсы через регулярные интервалы (меньше, чем время поддержания активности сети, но больше, чем максимальное время приема-передачи) на все узлы, является обязанностью руководителя.
Ваш балансировщик нагрузки должен обновлять лидера каждый раз, когда он получает сердцебиение. Балансировщик нагрузки будет отправлять данные только лидеру, так как согласно алгоритму рафта все клиентские запросы напрямую направляются только лидеру, другие узлы не могут отправлять данные, а только подтверждают команды голосования и добавления.
Здесь действительно хорошая презентация:- Плот: Репликация журнала