コンセンサスアルゴリズム-raft

コンセンサスアルゴリズム

コンセンサスアルゴリズムは、マシンの集合は、そのメンバーの一部の障害を生き残ることができるコヒーレントグループとして動作することができます。

プライベートチェーン：（ブロック鎖の概念と比較して）、分散コンセンサスアルゴリズムの伝統的なシステムは、そのような飼育係のZAB契約、パクシ、いかだのように。システムが唯一のノードまたはネットワーク障害の原因を考慮するため、クラスタ内のノード悪の存在を考慮せずにプライベートチェーン。

連合チェーン：クラスタ内のノード悪の存在を考慮する必要があり、また、クラスタ内のノードを検討する障害が発生しました。連合チェーンについては、それぞれの新しいノードを検証し、監査のために必要とされます。例えばpbftアルゴリズム

パブリック・チェーン：そこにネットワーク内のノードを検討する障害があるが、また、チェーンとの提携に類似している邪悪なノードを、検討する必要があります。連合のチェーンとの最大の違いは、公共チェーンノードが自由に参加したり終了し、厳格な検証と監査を必要としないということです。例のpow.pos、障害者団体、リップルのために

いかだとパクシ

プロトコルのクラスをまとめているパクシ

基本パクシ

マルチパクシ島のリーダーを強化します

マルチパクシ島のようなビットをいかだ

いかだアルゴリズム

二つの紙

エッセイ「よくわかるコンセンサスアルゴリズムの検索で」

大きな紙[「コンセンサス：BRIDGINGの理論と実践」]

いくつかのオープンソースプロジェクト実施し、etcd、tidb / tikv、領事

アルゴリズムの概要

シンプルないかだアルゴリズムを処理

一貫性の問題に対処するためのリーダーノードによって筏アルゴリズム。リーダーノードは、リーダーノードは、その後、他のロギングノードが正常にコピーされたクラスタを通知する場合、ログはより多くのノードの半分以上に同期されたとき、複製、に提出することができ、クライアントからの要求ログデータを受信し、クラスタノードで他人に同期いかだステートマシンの実行。

上記のようにして、整合性の問題を解決するためにラフトアルゴリズムは、以下のサブ問題に分割されます。

リーダー選挙：クラスタノードのリーダーが存在しなければなりません。
レプリケーションを記録します：リーダーノードは、クラスタ内の他のノードにログデータにクライアントからの要求、その後、これらの要求の再同期シーケンスを受け取ります。
セキュリティ：ノードが実装されているデータ入力状態機械のいかだを提出した場合は、他のノードから別のログ・データが同じインデックス入力ステートマシンの実行をいかだすることはできなくなりました。
メンバーの変更（メンバーシップの変更）

リーダー選挙

节点刚启动，进入follower状态，同时创建一个超时时间在150-300毫秒之间的选举超时定时器。
follower状态节点主循环：
  如果收到leader节点心跳：
    心跳标志位置1
  如果选举超时到期：
    没有收到leader节点心跳：
      任期号term+1，换到candidate状态。
    如果收到leader节点心跳：
      心跳标志位置空
  如果收到选举消息：
    如果当前没有给任何节点投票过 或者 消息的任期号大于当前任期号：
      投票给该节点
    否则：
      拒绝投票给该节点
candidate状态节点主循环：
  向集群中其他节点发送RequestVote请求，请求中带上当前任期号term
  收到AppendEntries消息：
    如果该消息的任期号 >= 本节点任期号term：
      说明已经有leader，切换到follower状态
    否则：
      拒绝该消息
  收到其他节点应答RequestVote消息：
    如果数量超过集群半数以上，切换到leader状态
    
  如果选举超时到期：
    term+1，进行下一次的选举
复制代码

選挙を開始すると、フォロワーはオフィスのその用語の数をインクリメントして、候補状態に切り替わります。そして、クラスタ内の他のノードにRequestVote RPCリクエストを送信することにより、新たな選挙を開始します。次のいずれかが発生するまで、候補ノードは、用語れた状態に留まります。

ノード候補は、投票は、クラスタ内の他のノードの半分以上を受け取ったことを、選挙に勝ちました。別のノードが指導者になりました。単一ノードはすぐにリーダー時に選挙のタイムアウトになりません。

ログのレプリケーション

日志复制的流程大体如下：

每个客户端的请求都会被重定向发送给leader，这些请求最后都会被输入到raft算法状态机中去执行。
leader在收到这些请求之后，会首先在自己的日志中添加一条新的日志条目。
在本地添加完日志之后，leader将向集群中其他节点发送AppendEntries RPC请求同步这个日志条目，当这个日志条目被成功复制之后（什么是成功复制，下面会谈到），leader节点将会将这条日志输入到raft状态机中，然后应答客户端。

 committedIndex >= appliedIndex
复制代码

ラフトアルゴリズムは、次の2を維持し、前述のマッチングログを満たすために一緒にこれら二つの属性の役割（LogMatchは）属性：

二つの異なるログ期間内のエントリとは、同じインデックス番号、彼らは同じに格納されているコマンドを使用している場合。
ログ内の二つの異なるエントリが同じ用語のインデックスと番号を持っている場合は、それらの間のすべてのエントリはまったく同じです。

セキュリティ

完全主義リーダー：ログエントリが与えられた期間内に提出された場合、そのエントリは、指導者の在職期間のすべてのより多くに表示されます

broadcastTime << electionTimeout << MTBF