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