n 個のプロセス (n > 2) があるとします。そのうちの 1 つをアクティブにするという合意が必要です。そのため、どちらがアクティブかを決定するために、互いに投票する必要があります。
すべてのプロセスはいつでも失敗する可能性があります。可能であれば 1 つのプロセスをアクティブにしたいのですが...
同時に 2 つをアクティブにしてはいけません。(つまり、スプリットブレインを回避したい)
それらの間で利用可能な唯一の通信メカニズムは、pub-sub メッセージングです (ポイント ツー ポイントではありません)。
1 つ以上のデータベースが使用可能ですが、1 つのデータベースが単一障害点になることはありません。すなわち。すべてのプロセスが動作可能であり、1 つのデータベースが失われたために動作が妨げられるとしたら、非常に望ましくありません。
デザイン？どのようなメッセージを公開する必要がありますか?
仮説：
これはリーダー選挙であり、コンセンサス問題の一形態であり、時には2 人の将軍の問題とも呼ばれます。いくつかの仮定 (完全に非同期であり、メッセージが失われる可能性がある) の下では、それは不可能であることが証明されており、その証明は特に洗練されています。
この問題の直観は次のとおりです。一定数のメッセージで合意に達することを可能にするアルゴリズムが存在すると想像してください。障害は許容されるため、プロトコルから 1 つのメッセージを削除できますが、それは引き続き機能するはずです。メッセージがまったくなくなるまで、このプロセスを繰り返すことができますが、明らかに不可能です。
実際には、故障検出器を使用して同期システムをシミュレートすることでこれを克服します。
コンセンサスを解決する最も広く知られているアルゴリズムはPaxosで、参加ノードの最大半分の障害を許容できます。Paxos は実装が非常に難しいという評判があり、プロトコルの詳細を少しでも誤解すると、その正確性が失われます。
実用的な解決策:
一般にこの問題は非常に難しいものですが、システムを稼働させるのははるかに簡単です。Paxos または同等のアルゴリズムの既製の実装が利用可能です。Apache Zookeeperは、私が知っている最高のものです。あなたの特定の問題については、それがあなたの最速のルートになると確信しています。他にも Paxos の実装があり、 Wackamoleのようなネットワーク冗長仮想 IP ツールで何かを構築することも可能かもしれません。ほとんどの商用データベースのハイエンド バージョンは、(高価な) オプションとしてクォーラム機能を提供していると思います。
また、多くのアプリケーションでは、正確性をわずかに弱めたり、問題を調整してより単純なソリューションを許可したりすることは許容されます。
たとえば、回復が迅速である可能性が高いために単一障害点が許容できる場合、問題は簡単です。1 つの特別なノードで作業を行うだけです。
別のアプローチとして、べき等アクションを中心にシステムを構築することも考えられます。これにより、重複した処理が許容されるようになります。
最後に、ワークロードを非冗長システムのプールに分割することもできます。この場合、障害によって回復まで処理が遅延しますが、ワークロード全体ではなく、そのノードの項目のみが遅延されます。
この種の妥協は非常に単純であるため、多くの場合、より良い選択となります。完全なソリューションの有用性と実装の複雑さを比較検討し、本当に価値があるかどうかを確認する必要があります。これが、非常に多くの実用的なシステムが2 フェーズまたは3 フェーズ コミットを使用するだけの理由です。一部のシナリオではブロックされますが、完全なクォーラム システムの複雑さに比べれば、可用性の低下は許容できます。
pub-sub メッセージングについてはよくわかりません。
彼らが外部ソースからある種の作業オブジェクトを取得していて、そのうちの 1 つだけが作業を処理するようにしたい場合は、ハッシュ値スペース 2^64 を取得し、各ノードが取得するノードの数でスペースを分割できます。チャンク。各ノードは、入ってくる作業オブジェクトをハッシュし、それが自分のものかどうかを判断できます。
ルーティングプロトコル（OSPFおよびIS-IS）がどのように機能するかを確認し、それが機能するかどうかを確認します。彼らはリーダー（そしてOSPFの場合はバックアップリーダー）を選出します。