一. 由來
如果你搭建過大型的分布式系統(tǒng)，那么一般你會用到zookeeper這個服務。該服務實現(xiàn)了ZAB算法。其通常會用在fail over選主，微服務上下游server配置中心等場景。但是ZAB和paxos有個缺點，就是理解性比較差。其論文內(nèi)容十分復雜，導致真正理解的開發(fā)人員非常少。【知乎：raft算法與paxos算法相比有什么優(yōu)勢，使用場景有什么差異】
二. raft 原理描述
【raft homepage】
【raft paper】
【live demo】
1. 選主Leader Election
raft和zookeeper類似，一般需要3或者5個node。這樣有利于判斷選舉的多數(shù)情況
node分為3個狀態(tài)：follower，candidate，leader
狀態(tài)的轉(zhuǎn)換
raft有2個timeout設(shè)置
1）從follow而轉(zhuǎn)換到candidate的timeout： election timeout，設(shè)置為：150ms到300ms中的隨機數(shù)。一個node到達這個timeout之后會發(fā)起一個新的選舉term（遞增的，大的表示新的），向其他節(jié)點發(fā)起投票請求，包括投給自己的那票，如果獲得了大多數(shù)選票，那么自己就轉(zhuǎn)換為leader狀態(tài)
2）node成為leader之后會向其他node發(fā)送Append Entries，這個時間為heartbeat timeout
如果lead在實際使用中down掉，剩下的節(jié)點會重新開啟1）和2）描述的選舉流程，保證了高可用性
特殊情況
如果集群中剩下偶數(shù)個node，并且在選舉的過程中有2個node獲得相等的選票數(shù)，那么會開啟新的一輪term選舉。知道有一個node獲得多數(shù)選票（隨機的election timeout保證可行）
2. 分布式系統(tǒng)中數(shù)據(jù)的一致性和高可用保證log replication
client給leader發(fā)送數(shù)據(jù)修改請求
leader通過Append Entries在心跳的過程中將修改內(nèi)容下發(fā)到follower nodes
在多數(shù)follower 接收了修改內(nèi)容返回后，leader向client確認
leader向follower發(fā)送心跳，具體執(zhí)行修改操作，此后數(shù)據(jù)在集群中保持一致
特殊情況
節(jié)點之前的網(wǎng)絡狀況十分不好，此時會有多個leader，其term也是不同的。
由于commit的修改需要多數(shù)通過，那么只有具有最多node的一個集群會commit修改成功。
當網(wǎng)絡狀況恢復，整個集群的節(jié)點會向多數(shù)節(jié)點的集群同步。這樣整個集群中的數(shù)據(jù)會繼續(xù)保持一致
3. raft集群擴容Membership Changes
live demo中沒有提及，但是paper中說明的內(nèi)容。
在實際使用中可有可能會遇到現(xiàn)有機器被新機器替換，或者為了提升穩(wěn)定性擴容raft集群的情況。作者給出了joint consensus的解決方案。其能保證切換過程是無縫的。
三. 在工業(yè)界系統(tǒng)的應用
-
【MySQL 三節(jié)點企業(yè)版】
mysql 三節(jié)點企業(yè)版
利用分布式一致性協(xié)議（Raft）保障多節(jié)點狀態(tài)切換的可靠性和原子性。 - 【RethinkDB: pushes JSON to your apps in realtime】
How is cluster configuration propagated?
Updating the state of a cluster is a surprisingly difficult problem in distributed systems. At any given point different (and potentially) conflicting configurations can be selected on different sides of a netsplit, different configurations can reach different nodes in the cluster at unpredictable times, etc.
RethinkDB uses the Raft algorithm to store and propagate cluster configuration in most cases, although there are some situations it uses semilattices, versioned with internal timestamps. This architecture turns out to have sufficient mathematical properties to address all the issues mentioned above (this result has been known in distributed systems research for quite a while)
What is failure tolerance?
An etcd cluster operates so long as a member quorum can be established. If quorum is lost through transient network failures (e.g., partitions), etcd automatically and safely resumes once the network recovers and restores quorum; Raft enforces cluster consistency. For power loss, etcd persists the Raft log to disk; etcd replays the log to the point of failure and resumes cluster participation. For permanent hardware failure, the node may be removed from the cluster through runtime reconfiguration.
It is recommended to have an odd number of members in a cluster. An odd-size cluster tolerates the same number of failures as an even-size cluster but with fewer nodes. The difference can be seen by comparing even and odd sized clusters:
etcd節(jié)點數(shù)與容錯能力數(shù)據(jù)：奇數(shù)個node有優(yōu)勢
Adding a member to bring the size of cluster up to an even number doesn't buy additional fault tolerance. Likewise, during a network partition, an odd number of members guarantees that there will always be a majority partition that can continue to operate and be the source of truth when the partition ends.
