[zookeeper]-raft协议

参考:https://raft.github.io/

工做原理

一、一个节点能够在3个状态中的1个 follower状态 candidate 状态 或者leader
二、咱们全部的节点都是从跟随者状态开始的
三、若是追随者没有听到领导者的消息，他们能够成为候选人
四、候选人而后请求其余节点的投票
五、节点将回复他们的投票
六、若是从多数节点得到选票，候选人就成为领导者。
七、这个过程被称为领导者选举
八、如今系统的全部变化都经过领导
九、每一个更改都添加为节点日志中的条目
十、此日志条目当前未提交，所以它不会更新节点的值
十一、为了提交条目，节点首先将它复制到跟随者节点
十二、这时领导等待，直到大多数节点已经写入条目
1三、该条目如今在领导者节点上提交而且节点状态为“5”
1四、领导者而后通知追随者该条目已经落实
1五、该集群如今已经就系统状态达成共识
1六、这个过程叫日志复制

raft 领导人选举

一、在raft里有两个超时设置来控制选举 二、首先是选举超时 2.1 选举超时是一个追随者在成为候选人以前等待的时间。 2.2 这选举超时是在150ms和300ms之间的随机数 3.在选举超时以后，追随者成为候选人并开始新的选举任期 四、选举本身 五、并发送请求投票消息给其余节点。 六、若是接收节点还没有在此期间投票，那么它会为候选人投票 七、而且该节点重置其选举超时 八、一旦候选人得到多数选票，它就成为领导者。 九、领导者开始向追随者发送附加条目消息。 10.这些消息以心跳超时指定的间隔发送。
十一、追随者而后回应每一个追加条目消息 十二、这个选举任期将持续到跟随者中止接受心跳并成为候选人

让咱们中止领导人，并观看从新选举

一、Node B如今是第2任期的领导人 二、要求多数选票保证每一个任期只能选举一名领导人 三、若是两个节点同时成为候选，则可能发生分裂投票。 四、让咱们来看看一个分割投票的例子… 4.1 两个节点都开始选举相同的期限.. 4.2 而且每一个都在另外一个节点以前到达单个跟随器节点 4.3 如今每一个候选人有2票，而且不能再收到这个任期 4.4 节点将等待新的选举并再次尝试

日志复制

1.一旦咱们选出了一个领导者，咱们就须要把咱们的系统的全部变化复制到全部节点上
二、这是经过使用用于心跳的相同附加条目消息来完成的
三、首先客户端发送变化给leader
四、这一变化被加到领导的日志上。
五、而后在下一次心跳中将变化发送给追随者。
六、一旦大多数追随者认可，就提交一个条目。
七、并将响应发送给客户端
八、如今让咱们发送一个命令，经过“2”来增长值

raft和zab关系

由于raft比zab出来晚点,可能raft 里面的有些东西会借鉴zab协议.其实两个协议差不到哪里去,本质上都是维护一个replicated log. 相同点(不全,没有实现过zab): 都使用timeout来从新选择leader. 采用quorum来肯定整个系统的一致性(也就是对某一个值的承认), 这个quorum通常实现是集群中半数以上的服务器, zookeeper里还提供了带权重的quorum实现.都由leader来发起写操做.都采用心跳检测存活性. leader election都采用先到先得的投票方式.

不一样点(不全,没有实现过zab): zab用的是epoch和count的组合来惟一表示一个值, 而raft用的是term和index.zab的follower在投票给一个leader以前必须和leader的日志达成一致, 而raft的follower则简单地说是谁的term高就投票给谁. raft协议的心跳是从leader到follower, 而zab协议则相反.
raft协议数据只有单向地从leader到follower(成为leader的条件之一就是拥有最新的log),

而zab协议在discovery阶段, 一个prospective leader须要将本身的log更新为quorum里面最新的log,而后才好在synchronization阶段将quorum里的其余机器的log都同步到一致.