問題タブ [raft]

etcd クラスターの現在のリーダーを特定する簡単な方法はありますか (ログを検索する場合を除く)。

RAFT 分散コンセンサス アルゴリズムを使用して、1 回の呼び出しで分散メッセージ ブローカーを構築します。ブローカーには、サブスクライバーへのメッセージの順序どおりの配信をサポートする追加機能もあります。トピックに属するメッセージは、ブローカーによって受信された順序で配信されます (プル モデルの場合はサブスクライバーからプルされます)。

これらの機能を備えたメッセージ ブローカーの使用例の 1 つはジョブ キューです。これは、ジョブが決して失われず (永続的)、到着順に完了する必要があるためです。

このようなメッセージ ブローカーの他の使用例は何ですか? 例を教えてください

etcd に関する「アトミック」更新とは何かを理解しようとしています。

私が「アトミック」と考えるとき、「前」と「後」があると思います (中はなく、更新が失敗した場合でも「前」です)。

次に例を示します。

したがって、この時点で、誰でもそのメッセージにアクセスして現在の値を取得できます。

後で、この値を次のように変更できます。

そして、前と同じように結果を取得できます。変更前は値 'Hidee Ho' が返され、変更後は値 'Mr Hanky' が返されます。それで、私の質問は、どちらかの結果が保証されているのですか? つまり、どちらか一方が返されることを確認したい (結果の間にnil値ではない)。

タイミングは特に気にしません。Mr Hanky の更新を行い、その後の値のフェッチャーが (短い) 期間、Hidee Ho を取得し続ければ、それで問題ありません。

プロトコルにAtomic CompareAndSwap関数があるため、混乱しています。私が知る限り、それは「値が私が言うとおりの場合にのみ更新を行う」ほどアトミックではありません。私の場合、以前の値はあまり気にしません。変更されたこと、および「前」または「後」の値以外は読者に表示されないことを知りたいだけです。

リーダーがログ エントリを取得すると、それをクラスタ内の他のサーバーに複製します。次に、エントリをコミットし、他のサーバーにもコミットするように指示します。ここには 2 つのケースがあるようです:
1) リーダーがエントリをコミットし、他のサーバーにもコミットするように指示します。
2) リーダーは全員にコミットするように言い、それからリーダーも実行します。

#1 で、他の人にコミットするように指示する前にリーダーがクラッシュした場合、コミットされていなくても、新しいリーダーになる人は誰でもエントリを使用しますか? そうでない場合は、最新のエントリと同期していないログがいくつかあります。(古いリーダーはそれを適用し、他のリーダーは適用しなかったでしょう。) もしそうなら、それをコミットしても問題ないことをどうやって知るのでしょうか?

＃2では、リーダーがコミットする前にクラッシュした場合、コミット後に他のすべてのノードがクラッシュし、選挙で古いリーダーが再び新しいリーダーになり、他のサーバーは新しいリーダーがコミットしていないエントリをコミットしました持っていません。この場合はどうなりますか？

2001、2002、2003、および 2004 の 4 つのノードのクラスターがあります。それらは goraft を使用してバインドされています。2001 年がマスター サーバーであるとします。失敗すると、別のノードがサーバーになります。今私が欲しいのは、現在のサーバーになるノードが、私が新しいリーダーであるというメッセージを送信する必要があるということです。では、それを達成する方法は？GORAFD 実装で GORAFT を使用しています。ここにソースコードを添付しています。

main.go - クライアント向け

Main.go - Server ie 2001 用

一般的な Server.go コード

いくつかの解決策を教えてください。

Raft アルゴリズムの論文を読み、Raft がクライアント リクエストを受け取ったときに実行する操作のシーケンスに関連する質問を受けました。

単一障害点のシナリオを克服するために、Raft は他のマシンで複製されたログを維持することに依存しています。アルゴリズムは、完全なログ管理のためにコンセンサス モジュールも参照します。一連の操作は次のように機能します。

1. クライアント要求はリーダーのステート マシンで受信され、リーダーはそのログにコマンドを追加します。
2. リーダーはAppendEntries RPC をフォロワーに送信してローカル ログにコマンドを複製し、フォロワーの大多数から、エントリがローカル ログ ファイルに正常に追加されたことを確認するのを待ちます。
3. リクエストがフォロワーログの大部分に正常に記録されたという確認が受信されると、リクエストはリーダーのステートマシンにコミットされ、遷移が発生し、その遷移の出力がクライアントに返されます。
4. 最終的に、リーダーは後続のAppendEntries RPC でコミットされたエントリをフォロワーに通知します。

上記の理解が正しければ、レプリケーション プロセスが完了するまでクライアント リクエストがしばらく保留されていると主張できます。また、クライアント リクエストの成功はレプリケーションの成功に大きく依存していると主張することもできます。プロセス (クライアントのコマンド/リクエストは、過半数の承認が受信されるまでリーダーのマシンで実行されないため)。問題は、レプリケーション手順が完了した後、クライアント リクエストが応答を受信するまでに平均でどれくらいの時間がかかると予想されるかということです。これは、リアルタイム システムでも効率的に機能しますか?