いじめアルゴリズムの説明では、通常、実際の失敗の検出については触れていません。
私は、失敗が選挙を引き起こすのではなく、選挙自体を使用して失敗を検出するいじめっ子アルゴリズムの実用的な実装を持っています。
要するに、私の実装での選択は、障害の検出時ではなく、スケジュールに基づいて実行されます。
明らかに、これはネットワーク トラフィックが生成されることを意味しますが、そうでなければ複雑になる可能性があるもの (たとえば、独自のネットワーク トラフィックを持つ別の障害検出メカニズムを持つこと) に対する単純なソリューションのように思えます。
誰でもこれに問題がありますか？
分散システムに 4 つのノード A、B、C、D があるとします。現在のリーダーが A であると仮定します。選択は、ノード B、C、または D のいずれかが、コーディネーター A が応答していないことを識別した場合にのみ発生します。リーダー A の失敗は、メッセージのタイムアウトまたはコーディネーターがハンドシェイクを開始できなかったために理解されます。標準のいじめアルゴリズムのアルゴリズムとは異なり、選挙は、コーディネーターに障害が発生した場合、またはより高いプロセス ID を持つ新しいノードが導入された場合にのみ実行されます。
通常、メンバーがもうリーダーがいないと疑うとき、つまり (ローカル) タイムアウトの後、リーダーの選出が開始されます。多くの場合、ローカル タイムアウトは十分ではありませんが、さらにリーダーの期待されるアクションです。
このスキームを適用すると、定期的な再選択も特別な障害検出も必要ありません。