本文已参与「新人创作礼」活动，一起开启掘金创作之路。
主要三种
【Paxos算法】 是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法
【 ZAB协议 】 全称就是ZooKeeper Atomic Broadcast protocol，是ZooKeeper用来实现一致性的算法，是基于 Paxos 算法实现的。
【Raft算法】 是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法。
1. Paxos算法****
Paxos[ˈpæksoʊs]算法解决的问题正是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。
(1) 半数理论****
Paxos算法运行在允许宕机故障的异步系统中，不要求可靠的消息传递，可容忍消息丢失、延迟、乱序以及重复。它利用大多数 (Majority) 机制保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障，即半数以上可用即可
(2) Paxos角色****
Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner)
Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。
Acceptor：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。
Learner：不参与决策，从Proposers/Acceptors学习最新达成一致的提案（Value）。
(3) Paxos 的决议通过****
一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)，Paxos算法使所有提案中的某一个提案，在所有进程中达成一致。系统中的多数派同时认可该提案，即达成了一致。最多只针对一个确定的提案达成一致。
Paxos算法通过一个决议分为两个阶段（Learn阶段之前决议已经形成）：
Acceptors 通过全局唯一且递增的Proposal ID保证不会允诺和发起更旧的提案，也就是保证最新****
2. ZAB协议****
ZAB协议，全称 Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。它是专门为分布式协调服务Zookeeper，设计的一种支持崩溃恢复和原子广播的协议。实现分布式的数据一致性。
(1) Zab 通常处于两个阶段(状态)****
1) 消息广播阶段
Leader 节点接受事务提交，并且将新的 Proposal（提议） 请求广播给 Follower 节点，收集各个节点的反馈，决定是否进行 Commit。
2) 崩溃恢复阶段
如果在同步过程中出现 Leader 节点宕机（或初始化时，或失去半数机器支持），会进入崩溃恢复阶段，重新进行 Leader 选举，崩溃恢复阶段还包含数据同步操作，同步集群中最新的数据，保持集群的数据一致性
崩溃恢复完成选举以后，接下来的工作就是数据同步，在选举过程中，通过投票已经确认 Leader 服务器是最大Zxid 的节点，同步阶段就是利用 Leader 前一阶段获得的最新Proposal历史，同步集群中所有的副本。
(2) Zab协议核心****
Zab协议的核心：定义了事务请求的处理方式
所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被叫做 Leader服务器。其他剩余的服务器则是 Follower服务器。
Leader服务器 负责将一个客户端事务请求，转换成一个 事务Proposal，并将该 Proposal 分发给集群中所有的 Follower 服务器，也就是向所有 Follower 节点发送数据广播请求（或数据复制）
分发之后Leader服务器需要等待所有Follower服务器的反馈（Ack请求），在Zab协议中，只要超过半数的Follower服务器进行了正确的反馈后（也就是收到半数以上的Follower的Ack请求），那么 Leader 就会再次向所有的 Follower服务器发送 Commit 消息，要求其将上一个 事务proposal 进行提交。【类似两阶段提交，广播事务操作，再广播提交操作】
3. Raft协议****
Raft是一种易于理解的分布式一致性算法
(1) Raft节点状态****
一个Raft集群包含若干个节点，这些节点分为三种状态：Leader、 Follower、Candidate。
正常情况下，集群中的节点只存在 Leader与Follower两种状态，只有选举时才转成Candidate。
leader：负责日志的同步管理，处理来自客户端的请求，与Follower保持heartBeat的联系；
follower：响应 Leader 的日志同步请求，响应Candidate的邀票请求，以及把客户端请求到Follower的事务转发（重定向）给Leader；
candidate：负责选举投票，集群刚启动或者Leader宕机时，状态为Follower的节点将转为Candidate并发起选举，选举胜出（获得超过半数节点的投票）后，从Candidate转为Leader状态。
(2) 任期****
还有一个关键概念：term（任期）。以选举（election）开始，每一次选举term都会自增，充当了逻辑时钟的作用。
(3) 一致性问题分解****
为简化逻辑和实现，Raft 将一致性问题分解成了三个相对独立的子问题。
选举（Leader Election）： 当 Leader 宕机或者集群初创时，一个新的 Leader 需要被选举出来；
日志复制（Log Replication）： Leader 接收来自客户端的请求并将其以日志条目的形式复制到集群中的其它节点，并且强制要求其它节点的日志和自己保持一致；
安全性（Safety）： 如果有任何的服务器节点已经应用了一个确定的日志条目到它的状态机中，那么其它服务器节点不能在同一个日志索引位置应用一个不同的指令。
(4) 触发选举****
如果follower在election timeout内没有收到来自leader的心跳，则会主动发起选举。
(5) 选举过程****
第一阶段：所有节点都是 Follower。
所有节点的状态都是 Follower，初始 Term（任期）为 0。同时启动选举定时器，每个节点的选举定时器超时时间都在 100~500 毫秒之间且并不一致。
第二阶段：Follower 转为 Candidate 并发起投票。
没有leader后，followers状态自动转为candidate，并向集群中所有节点发送投票请求并且重置选举定时器。
第三阶段：投票策略
在一个term内，一个节点只允许发出一次投票
(6) 复制状态机(replicated state machine)****
Raft协议可以使得一个集群的服务器组成复制状态机
每一个状态机存储一个包含一系列指令的日志，严格按照顺序逐条执行日志中的指令，如果所有的状态机都能按照相同的日志执行指令，那么它们最终将达到相同的状态。因此，在复制状态机模型下，只要保证了操作日志的一致性，我们就能保证该分布式系统状态的一致性。
相同的初识状态 + 相同的输入 = 相同的结束状态
(7) Raft一致性算法****
在Raft体系中，有一个强leader，由它全权负责接收客户端的请求命令，并将命令作为日志条目复制给其他服务器，在确认安全的时候，将日志命令提交执行。
客户端的一切请求都发送到leader，leader来调度这些并发请求的顺序，并且保证leader与followers状态的一致性。raft中的做法是，将这些请求以及执行顺序告知followers。leader和followers以相同的顺序来执行这些请求，保证状态一致。
步骤：****
①leader append log entry leader追加日志条目
②leader issue AppendEntries RPC in parallel leader将追加条目通过RPC同步发送给followers
③leader wait for majority response leader等待多数followers的回应
④leader apply entry to state machine leader将条目应用到状态机
⑤leader reply to client leader回复客户端
⑥leader notify follower apply log leader通知followers应用日志
raft与其他协议（Viewstamped Replication、mongodb）不同，raft始终保证leader包含最新的已提交的日志，因此leader不会从follower catchup日志，这也大大简化了系统的复杂度。
