ラフト契約備考

ラフト契約

一貫性を達成するために、ログに基づいて、ラフトプロトコル

バックアップの仕組みは次のとおりです。コピーステートマシン複製された状態マシンは、同じ状態から起動するには、2つの同一の、決定論的なステートマシン、同じログを入力するのと同じ順序あれば、2台の状態マシンは最終的に一貫して

実現コンセンサスモジュールをいかだ

外部サービスとしてコンセンサスモジュールの整合性モジュールは、クライアントが上の各マシンの一貫性を確保するために、整合性モジュールログインし、要求に応じて、メッセージを受信するための責任があり、そしてローカルログに追加
要求が到着、持参（用語、commitindex）と追加します同じことが、それ以外の場合は拒否されます、追加される場合、追加の情報を記録するために必要なフォロワ、フォロワは、まず、（用語、インデックス）と同一のメッセージの現在の最大値か否かを決定する
ローカルログがインスタント成功をコミットし、整合性モジュールは、他のサーバノードにメッセージをコピーする責任を負いますステートマシンへの応用

サーバーノードを増加または減少させるためCNewケース

リーダー：メッセージの処理、クライアントとの対話を扱う
フォロワー：有権者が、リーダーに要求を転送
候補：候補者、選挙ではなく、すべてのフォロワーのは、候補者、データのみより完全な缶になることができ、リーダーになることができます。候補者は、用語の後ろに自分自身を発見した場合フォロワーに返されます

RequestVote：選挙時のRPCメッセージ
AppendEntries：フォローするRPCメッセージのログをコピーした後選出リーダー、ハートビートはAppendEntriesですが、ログは空です

いかだ原則合意

選挙セイフティ：オフィスの各用語は唯一のリーダーであります
リーダー追加のみ：リーダー新しいログのみ、あなたが書き換えたり、ログエントリを削除することはできません
もし二つの同一の対数項と同じインデックス、2台のステート・マシン：ログマッチ
リーダーの完全性：ログがあまりにもコミットされた場合は、すべてのノードの用語のエントリの日付よりも大きいが、このエントリを持っている必要があります
サーバーログは、ステートマシンの処理に引き渡された場合にログエントリのまったく同じ数、ステートマシンの実行に引き渡され、すべてのサーバー：ステートマシンセイフティ

選挙セイフティ

キャンペーンのリーダー、候補者が票の半分以上を取得する場合、あなたはリーダーになることができ
、我々は自分自身のためのすべての投票が表示される場合は二台のマシンは、それぞれの投票の一般的な数、再選ランダムスリープを受け取ります
先着
フォロワーがルールに従います。自分自身よりも大きな選挙の用語 - 自分より>指数も大きく、それ以外の選挙は候補者ではないだろう
ランダムタイムアウト、速く選出された指導者
あなたが候補者に投票した場合は、のために投票する人の永続的な記録を必要とし、それ以外の場合は、投票前と後のフォロワーの再起動は、異なるにつながる可能性がある場合

ログマッチ

リーダーは、複製ログをフォロワした場合、最新のもたらす用語、インデックス、フォロワーが要求を受信する（ログが前に）、それは最初の一致が追加されます彼らの最新のログ用語やインデックスを、比較、または拒否します、このリーダーで、用語やインデックスを見つけるために前方に移動し、フォロワーの成功を一致させようとした後、フォロワーに開始位置からログをコピーします

リーダー完全性

ログがポイントとしてタスク以内に提出することはできません前にコミット

予備選挙

あなたが特定の時間にフォロワーリーダーのハートビートを受信しない場合は、選択したマスタ再起動
フォロワーが自分のステータスが候補に変更置き、現地語をインクリメントし、永続的な、他のマシンに、そして彼らの投票に遊説、およびまで待ちます

投票の過半数を取得するには、選挙に勝つために主な候補者
他のマシンは、ハートビートがネイティブ用語未満でない用語を発見し、自動的にフォロワーになる、リーダーになり、
タイムアウトは、予備選挙の成功を失敗しました
すべてのホストを含めるようにしてくださいログが候補になることができますコミット
少なくとも過半数の選挙の候補とホスト通信、ときに、このマシンの項より候補、logindexも時間、フォロワーが投票に拒否することがわかりました

コミットするか否かを判断する方法

リーダーは、ディスク書き込みの大半をホストログオンすることが見出された、私がコミットさだと思います

CNew、クラスタトポロジの変更

彼らはフォロワートポロジーを発見していない場合Cnewは、送出され、終了

ませんlogEntryコールドU Cnewを生成します
プッシュフォロワー
もっとコミットの半分以上
CNewログエントリを生成し、すべてのフォロワーをプッシュ
フォロワーは自動的に終了し、その後、Cnewの構成を更新し、現在のノードがもはや新しい構成であれば、クラスタ内の自分の位置を理解していません
院内総務は、確認の受領後、コマンドを実行して成功したクライアントに返信します

いいえOPエントリーません

リーダー選挙が終了したばかりの後、いくつかのエントリがあるかもしれませんが、すでに提出され、一部がコミットされない、OPエントリフォロワーがコンセンサスに到達しないと同じ時間を確保するために、だけでなく、新しい要求にクライアントを防ぐために提出する必要があります時間内に到着しない後

疑い

ステートマシンがの一貫性を保証する場合コミットあれば終わりでは、ラフトは、
ケース1：
クライアント- >リーダー- >ログAppendEntries - >大半の確認- >がコミットされました- >リターン・クライアント：成功した
彼らも再場合、マシンに最も持っているので、予備選挙、彼らは確かに最新のログとなります
が、これはない
ケース2：
クライアント- >リーダー- >ログAppendEntriesは- >コミットをしない- -過半数を確認するために取得していない>>リターン・クライアント：失敗の再試行は
に戻りましたネットワークから切断リーダーは、リーダーとして選択されている例のセクションを確認するために表示される可能性がある場合、クライアントは、この時間を失敗しましたか？それは本当の成功ではないでしょう

次の属性の維持は、この問題を説明できるかどうかをいかだ：

そこに、ログファイルに2つの異なるエントリがあり、同じ索引語を持っている場合は、同じコマンドが格納されています。
別のログファイルが同じインデックスと用語との2つのエントリがある場合は、すべての以前のエントリは同じです。
それだけでは大多数のフォロワーがコミットと思うだろうことを確認しました

上記の特徴によれば、状況は2が表示されたら、3の特性を満たしていないことは、応答を受信するクライアントに障害が発生し、その場合には、それが何をすべきそれが成功するまで再試行を維持することです、そのいかだプロトコルは、あなたがしたい場合も、クライアントを必要とするように、ケース3を可能に強い一貫性、あなたは常に再試行する必要があり
いかだ提出ログの一貫性を確保します

フォロワーは彼の言葉を発見し、実行する方法よりも大きなリーダーをlogindex？
フォロワー？に縮退切り捨てられたか、リーダー
語ったフォロワーログが送信されたときにリーダー？
ラフトの制約が継続的に、コミットログをリーダー最大はすでにログIDをコミット維持し、この情報はフォロワー通知AppendEntriesに追加され、このユニットは、すでにコミットログを持ち、学んだフォロワー後にローカルステートマシンに適用することができています。

参考記事
https://blog.csdn.net/weixin_39843367/article/details/82498536
https://blog.csdn.net/baijiwei/article/details/78760308