問題タブ [raft]

パクシやいかだの代わりにCRDTのようなものを使用するのはいつ良い考えですか？

raft コンセンサス アルゴリズムは、 MongoDB がプライマリを選択する際に他の要因 (優先度など) を考慮に入れるという事実以外に、MongoDB のプライマリ選択プロセスとどのように異なるのですか?

実装 RAFT について次の質問があります。

次のシナリオ\実装を検討してください。

1. RAFT リーダーはコマンド エントリを受信し、エントリをメモリ内配列に追加します。次に、エントリをフォロワーに送信します (ハートビートを使用)。
2. フォロワーはエントリを受信し、それをメモリ内配列に追加してから、エントリを受信したという応答を送信します。
3. 次に、リーダーはエントリを永続的なストア (ファイル) に書き込むことでコミットします。リーダーは最新のコミット インデックスをハートビートで送信します。
4. 次にフォロワーは、エントリを永続ストア (ファイル) に保存することにより、リーダーのコミット インデックスに基づいてエントリをコミットします。

RAFT の実装の 1 つ (リンク: https://github.com/peterbourgon/raft/ ) は、このように実装しているようです。これでいいのか確認したかった。

エントリがコミットされるまで、リーダーとフォロワーによって「メモリ内」に維持されていても問題ありませんか? このシナリオはどのような状況で失敗する可能性がありますか?

紙が言うように：

選挙の安全性: 任期中に選出できるリーダーは最大 1 人です。§5.2

ただし、システムには複数のリーダーが存在する場合があります。Raft が約束できるのは、与えられたタームに 1 人のリーダーしかいないということだけです。では、複数のクライアントを持っている場合、異なるデータが得られるのではないでしょうか? これにより、Raft がコンセンサス アルゴリズムになるにはどうすればよいでしょうか?

ここで私が理解できないこと、誰かが説明できることはありますか?

これは非常に単純な質問かもしれませんが、これに対する適切な答えをまだ見つけることができませんでした。多分誰かが私を助けることができます。

リーダーが選出されると、

1. クライアントはすべてのリクエストをリーダーのみに送信します。これは正しいです？
2. リーダーの場所 (すべての実用的な目的では IP アドレス) が動的であるとすると、クライアントはクラスター内のこの IP アドレスをどのように知るのでしょうか?

私はこのようなgoコード関数を手に入れました。私が混乱しているのは、なぜatomicここに必要なのですか? これは何を防いでいるのですか？

ありがとう。

Raft クラスターでは、各ログ エントリは、ログ インデックス (ログの順序でこのエントリが発生する場所) とログ期間 (エントリが発生した「期間」。選択ごとに期間がインクリメントされる) を持つと見なすことができます。

例えば、

ここで、四角はログ エントリを表します。四角の中の数字は、ログの各エントリの期間を表します。四角の位置 (および最上部の数字) は、ログの各エントリのインデックスを表します。

Raft ログのログ インデックスとログ タームは際限なく大きくなりますか?

いいえの場合、これらの変数をどのように「リセット」しますか?

はいの場合、実装 (etcd や ZooKeeper など) はこれらの無制限の拡張をサポートしていますか? それとも、固定サイズの整数型を使用し、それらの変数がオーバーフローしないと想定していますか?

Raft、Paxos、Zab などの現在のマスター選出アルゴリズムがクラスターでマスターを選出する方法を読みましたが、単純ないじめアルゴリズムではなく洗練されたアルゴリズムを使用する理由を理解できませんでした。

クラスタ ライブラリを開発しており、ハートビート メッセージに UDP マルチキャストを使用しています。各ノードはマルチキャスト アドレスに参加し、定期的にデータグラム パケットをそのアドレスに送信します。ノードが、このマルチキャスト アドレスにパケットを送信する新しいノードがあることを検出した場合、そのノードは単にクラスターに追加されます。同様に、クラスター内のノードがノードからパッケージを取得しない場合、ノードはクラスターから削除されます。マスター ノードを選択する必要がある場合は、クラスター内のノードを反復処理して最も古いノードを選択するだけです。

このアプローチは効果的ではなく、Paxos のようなより洗練されたアルゴリズムを使用して、マスターを選択したり、ハートビート メッセージを介して障害を検出したりする必要があることを示唆する記事をいくつか読みました。Raft を使用せずにノードのクォーラムがいつクラスターから離脱するかを簡単に見つけることができるため、Paxos が従来のいじめアルゴリズムよりもスプリットブレイン シナリオやその他のネットワーク障害に適している理由を理解できませんでした。唯一の利点は、各サーバーが処理しなければならないパケットの数です。マスターのみが Raft でハートビート メッセージを送信しますが、この場合、各ノードはハートビート メッセージを相互に送信する必要があります。ただし、マスター選択アルゴリズムを変更せずに同様のハートビート アルゴリズムを簡単に実装できるため、これは問題ではないと思います。

誰かがそれについて詳しく説明できますか？