数据一致性的分类
①强一致性：如果数据不一致，就不对外提供服务，保证用户读取到的数据始终是一致的，只需要通过锁机制解决即可。
②最终一致性：要求数据最终同步即可，没有实时性要求。
CAP原则
CAP在分布式系统中主要指一致性Consistency、可用性Available和分区容错性Partition tolerance。
①一致性：指数据强一致性
②可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定响应时间内响应请求，超出时间范围认为系统不可用
③分区容错性：分布式系统在遇到任何网络分区故障时，仍需要能够保证对外提供一致性和可用性服务，除非是整个网络都发生故障。
在一个分布式系统中不可能同时满足CAP，最多满足两个，对于分布式互联网应用而言必须保证P，所以要么满足AP模型，要么满足CP模型。
一致性协议
事务需要跨多个分布式结点时，为了保证事务的ACID特性，需要选举出一个协调者来协调分布式各个结点的调度，基于这个思想衍生了多种一致性协议
2PC 二阶段提交
- 阶段一 提交事务请求
①协调者向所有参与者发送事务内容，询问是否可以执行事务操作，并等待其他参与者结点的反馈。②各参与者结点执行事务操作。③各参与者结点反馈给协调者，事务能否执行。 - 阶段二 事务提交
根据阶段一各个参与者结点反馈的ack分为不同情况，如果所有参与者反馈ack则执行事务提交，否则中断事务。
事务提交：①协调者向各个参与者结点发送commit请求。②参与者接收到后执行事务提交，并向协调者反馈。③协调者接收反馈后完成事务提交。
事务中断：①发送回滚请求。②各个参与者回滚事务并反馈结果。③协调者接收反馈并回滚事务。
二阶段提交存在的问题：
①同步阻塞：二阶段提交过程中，所有参与事务操作的结点处于同步阻塞状态，无法执行其他操作。
②单点问题：一旦协调者出现单点故障，无法保证事务的一致性操作。
③脑裂导致数据不一致：如果分布式结点出现网络分区，某些参与者未收到commit提交命令，则出现部分参与者完成数据提交，未收到commit命令的参与者则无法完成事务提交，整个分布式系统便出现了数据不一致性问题。
3PC 三阶段提交
3PC是2PC的改进版，实质是将2PC中提交事务请求拆分为2步，形成CanCommit、PreCommit、doCommit三个阶段的事务一致性协议。
- 阶段一 canCommit
①事务询问②参与者阶段反馈询问响应 - 阶段二 preCommit
根据阶段一分为两种情况：
事务预提交：①协调者向所有参与者结点发送预提交请求，进入prepared阶段。②各参与者结点接收到预提交请求，执行事务操作，反馈。
中断事务：任意一个参与者结点反馈no或等待超时后协调者还未收到参与者反馈就中断事务。①协调者向各个参与者发送abort请求。②参与者收到后，或者等待超时时间后中断事务。 - 阶段三 doCommit
事务提交：①协调者发送提交请求②各个参与者接受提交请求，提交事务，并反馈。③协调者收到各个参与者的ack后完成事务。
事务中断：①参与者收到abort后，执行事务回滚，并反馈。②协调者接收回滚ack后，回滚事务。
相较于2PC解决了同步阻塞和单点问题（使用超时机制）。
Paxos算法
该算法是一种基于消息传递的提高分布式系统容错性的一致性算法，解决了3PC中网络分区的问题，paxos算法可以在节点失效，网络分区，网络延迟等各种异常情况下保证所有结点处于同一状态，同时引入了“过半”理念，即少数服从多数。
三个版本
- Basic Paxos
- Multi Paxos
- Fasr Paxos（zookeeper使用）
四种角色
- client 系统外部角色，请求发起者，不参与决策
- proposer 提案提议者
- acceptor 提案表决者，即是否accept该提案，只有半数以上的acceptor接受了该提案，该提案才被认定为“选定”
- learners 提案学习者，当提案被选定后，其同步执行提案，不参与决策
两个阶段
- prepare 准备阶段
①proposer提出一个提案，编号为N，发送给所有acceptor
②每个acceptor都保存自己的最大提案编号maxN，如果接收到的提案编号小于maxN则拒绝prepare(N)请求，不会响应；如果收到的提案编号大于等于maxN则接收该提案，更新maxN，并将该acceptor接受过的编号最大的提案Proposal（myid，maxN，value）反馈给提议者，其中myid表示决策者acceptor的标识id，maxN表示接受过的最大提案编号maxN，value表示提案内容。若当前表决者未曾accept任何提议会将proposal（myid，null，null）反馈给提议者。 - accept 接受阶段
①proposer发出prepare（N），若收到半数acceptor的反馈，将真正的提案内容proposal（N，value）发送给所有acceptor。
②acceptor接收proposal（N，value）后会将自己曾经收到的最大提案编号maxN和反馈过的prepare的最大编号与N比较，若N大于等于这两个编号，acceptor接受该提案并反馈给proposer，否则拒绝该提案，不响应。
③若提议者没有收到半数以上表决者反馈，则重新进入prepare阶段，递增提案编号，重新提出请求。若收到半数以上accept，则其他未向提议者反馈的表决者成为learner，主动同步提议者的提案。
活锁问题
任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试—失败—尝试—失败的过程。处于活锁的实体是在不断的改变状态，活锁有可能自行解开。
例如提议者1提交提案，决策者更新为1并响应，提议者1进入第二阶段。提议者2提交提案，决策者又更新为2并响应，提议者2进入第二阶段。这时提议者1发现已经更新为2，又提交了提案3，提议者2来时又发现变成3更新成4，如此循环谁都不能提交。
要解决活锁只需要稍微岔开执行时间就行。
ZAB协议
由于paxos算法实现困难，存在活锁和全序问题（无法保证两次最终提交的顺序），所以zookeeper并没有使用paxos作为一致性协议，而是使用了ZAB。
ZAB是一种支持崩溃恢复的原子广播协议，基于Fast Paxos实现。
zookeeper使用单一主进程leader处理客户端所有事务请求，即写请求。当服务器数据发生变更时集群采用ZAB原子广播协议，以事务提交proposal的形式广播到所有副本进程，每一个事务分配一个全局的递增事务编号xid。
若客户端提交请求为读请求，则接受请求的结点直接根据自己保存的数据响应。若是写请求且当前节点不是leader，那么就会转发请求给leader。leader会以提案的方式广播此请求，如果超过半数的节点同意写请求，则该写请求就会提交。leader会通知所有订阅者同步数据。
三种角色
为了避免单点问题，zookeeper使用集群方式保证高可用。
- leader
负责处理集群的写请求，并发起投票，只有超过半数结点同意后才会提交写请求 - follower
如果是读请求直接响应，如果是写请求转发给leader，在选举中参与投票 - observer
可以理解为没有投票权的follower，主要职责是协助follower处理读请求，不直接增加follower的原因是leader提出写请求时需要半数follower投票，过多follower会增加leader和follower的通信压力，降低写操作效率。
两种模式
-
恢复模式
当服务启动或者leader崩溃后，zk进入恢复状态，选举leader，选出后将完成leader和其他机器的数据同步，大部分服务器完成和leader的同步后恢复模式结束。 -
广播模式
一旦leader和多数follower进行状态同步后，进入广播模式。进入广播模式后如果加入了新的服务器，会自动从leader同步数据。leader在接收客户端请求后，会生成事务提案广播给其他机器，有半数follower同意该提以后再提交事务。
ZAB的二阶段提交移除了事务中断的逻辑，follower要么ack，要么放弃，leader无需等待所有follower的ack。
Zxid是64位的Long类型，高32位表示纪元epoch，低32位表示事务标识xid。
每个leader都会具有不同的epoch值，表示一个纪元，每一个新的选举开启时都会生成一个新的epoch，新的leader产生会更新所有的zkSever的zxid的epoch，xid是一个依次递增的事务编号。
选举算法
核心原则：
- zookeeper集群中只有半数以上服务器启动，才能正常工作
- 集群正常工作之前，myid小的服务器会给myid大的服务器投票，持续到集群正常工作或选出leader
- 选择leader后，之前的服务器状态由looking改为following，以后的服务器都是following
启动过程:
- 每一个server发出一个投票给集群中其他结点
- 收到各个服务器的投票后，判断该投票的有效性，比如是否是本轮投票，是否是looking状态
- 处理投票，pk自己的投票和别人的投票，比较规则：xid大的优先，如果相同比较myid
- 统计是否超过半数服务器接受相同投票
- 确认leader，改变服务器状态
- 添加新server，leader已经选举出来，以follower身份加入集群
崩溃恢复过程：
- leader挂掉后，集群中其他follower会将状态从following改为looking，重新进入leader选举，过程同上
消息广播算法
一旦进入广播模式，集群中非leader节点接收到事务请求，首先会将事务请求转发给leader，leader为其生成对应的事务提案proposal并发送给集群中其他结点，如果过半则事务提交。
- leader接收到消息后，消息通过全局唯一的64位自增事务id，Zxid标识。
- leader发送给follower的提案是有序的，leader会创建一个FIFO队列，将提案顺序写入队列中发送
- follower接收到提案后会比较提案Zxid和本地事务日志最大Zxid，若提案Zxid大则将提案记录到本地日志反馈ack给leader，否则拒绝
- leader接收到半数ack后，向所有follower发送commit，通知每个follower执行本地事务
zookeeper基本命令行
- ls 查看znode内容 使用watch时监听的是path
- ls2 ls加强，显示更多信息
- create 创建znode
- set 更改znode数据 使用watch时监听的是值
- get 获取znode数据
- stat 获取znode熟悉
- delete 删除znode
- rmr 递归删除znode
