Поскольку вам нужен протокол выбора лидера, звучит так, как будто вы хотите избежать, чтобы более чем один узел выступал в роли лидера одновременно. Ответ действительно зависит от того, насколько строго вам требуется это свойство. В некоторых случаях допустимо иметь более одного узла, выступающего в качестве лидера; возможно, худшее, что случается, - это дублирующая работа. В других случаях вся система может работать неправильно, если когда-либо есть дублирующие лидеры, поэтому вы должны быть более осторожны.
Если вы можете принимать случайные случаи дублирующих лидеров, тогда для вас может быть более простой протокол. Однако, если вы абсолютно не можете терпеть наличие более одного лидера одновременно, вам придется объединить протокол выборов своего лидера с некоторой репликацией состояния, и проверенная реализация Paxos или Raft или подобного является очень хорошим способом сделать это. , Для этого существует множество слегка отличающихся протоколов, но все они в основном делают одно и то же.
Фундаментальная проблема здесь заключается в том, чтобы определить, что означает "сразу" в реальной c сети, в которой сообщения иногда могут доставить после очень большой задержки. Как правило, предполагается, что сеть полностью асинхронна без временных ограничений при доставке, и, действительно, Paxos, Raft et c. все предназначены для правильной работы в этом предположении. Эти алгоритмы работают вокруг этого, определяя свое собственное внутреннее представление о времени (бюллетени в Паксосе, термины в Плоте) и привязывая это «внутреннее время» ко всем переходам состояний под их контролем. Это дает некоторые очень строгие гарантии и, в частности, гарантирует, что никакие два узла не могут выполнять действия в качестве лидера в одно и то же «внутреннее время».
Если вы не реплицируете какое-либо состояние через что-то вроде Paxos или Raft, тогда вы не сможете использовать это сильное понятие внутреннего времени.