zookeeper の leader 選挙には二つの段階があります。一つはサーバー起動時の leader 選挙であり、もう一つは稼働中に leader サーバーがダウンした場合です。選挙の原理を分析する前に、いくつかの重要なパラメータを紹介します。

• サーバー ID(myid)：番号が大きいほど選挙アルゴリズムにおける重みが大きい
• トランザクション ID(zxid)：値が大きいほどデータが新しいことを示し、重みが大きい
• 論理クロック(epoch-logicalclock)：同じラウンドの投票プロセスでは論理クロックの値は同じです。投票が一回終わるごとに値が増加します。

選挙状態：

• LOOKING: 選挙立候補状態
• FOLLOWING: フォロワー状態、leader の状態を同期し、投票に参加する
• OBSERVING: オブザーバー状態、leader の状態を同期し、投票には参加しない
• LEADING: リーダー状態

1、サーバー起動時の leader 選挙

各ノードは起動時には LOOKING の観望状態です。次に選挙のメインプロセスを開始します。ここでは3台のマシンからなるクラスタを例にとります。最初のサーバー server1 が起動した時は、leader 選挙を行うことができません。2台目のサーバー server2 が起動した時、2台のマシンは相互に通信できるようになり、leader 選挙プロセスに入ります。

• （1）各 server は1つの投票を出します。初期状態であるため、server1 と server2 はどちらも自分自身を leader サーバーとして投票します。各投票には推挙するサーバーの myid、zxid、epoch が含まれ、（myid、zxid）で表します。このとき server1 の投票は（1,0）、server2 の投票は（2,0）であり、それぞれの投票をクラスタ内の他のマシンに送信します。

• （2）各サーバーからの投票を受信します。クラスタ内の各サーバーは投票を受け取った後、まずその投票の有効性を判断します。例えば、今回のラウンドの投票（epoch）であるか、LOOKING 状態のサーバーからのものかをチェックします。

• （3）投票をそれぞれ処理します。各投票に対して、サーバーは他のサーバーの投票と自分の投票を比較する必要があります。比較ルールは以下の通りです：

  • a. まず epoch を比較する
  • b. zxid を確認し、zxid が大きいサーバーを優先的に leader とする
  • c. zxid が同じ場合は myid を比較し、myid が大きいサーバーを leader サーバーとする

• （4）投票を集計します。投票のたびに、サーバーは投票情報を集計し、過半数のマシンが同じ投票情報を受け取ったかどうかを判断します。server1、server2 はどちらもクラスタ内の2台のマシンが（2,0）の投票情報を受け入れたと集計し、この時点で server2 が leader ノードとして選出されました。

• （5）サーバーの状態を変更します。leader が確定すると、各サーバーはそれに応じて自分の状態を更新します。follower であれば FOLLOWING に変更し、Leader であれば LEADING に変更します。このとき server3 が引き続き起動し、直接参加して自分を FOLLOWING に変更します。

2、稼働中の leader 選挙

クラスタ内の leader サーバーがダウンした、または使用できない状態になった場合、クラスタ全体が外部にサービスを提供できなくなり、新たなラウンドの leader 選挙に入ります。

• （1）状態を変更します。leader がダウンした後、他の非 Oberver サーバーは自身のサーバー状態を LOOKING に変更します。
• （2）各 server は1つの投票を出します。稼働中、各サーバーの zxid は異なる可能性があります。
• （3）投票を処理します。ルールは起動プロセスと同じです。
• （4）投票を集計します。起動プロセスと同じです。
• （5）サーバーの状態を変更します。起動プロセスと同じです。