一、定义：基于消息传递的【一致性算法】
二、算法的前提：没有拜占庭将军问题；可信的计算机环境中才成立
三、故事描述
有一个叫做paxos的小岛，上面居住了一些居民
岛上的事情由一些特殊的人决定：议员（senator）
岛上环境事务的变更都需要通过一个提议（Proposal），每个提议都有一个编号（PID），这个编号是一直增长的，不能减少
每个提议都需要超过半数的议员同意才能执行（senator count/2 + 1）
每个议员只会同意大于当前编号的提议（包含已生效和未生效的），当前编号是议员自己记录的，每次会议并不能保证每个议员自己记录的当前编号是一致的
如果小于等于当前编号，则意味着已经有人提过了
会议的目的：所有的议员对于提议达成一致的看法
四、ZAB:基于paxos算法为zookeeper定制的分布式一致性算法
1、四个阶段：
- 选举阶段：发现leader挂掉了，需要重新选举
- 发现阶段：选出新的leader，进行连接，同步状态
- 同步阶段：同步leader上一阶段的副本数据
- 广播阶段：对外提供服务，消息广播
2、节点的三种状态：
- FOLLOWING：追随
- LEADING：领导
- LOKING：查找选举新Leader
3、特性：简单和快。虽然可以存储数据，但zookeeper的设计目标并非用于数据库使用，而是分布式协调。其要求的一些特性
- 高可用&故障容忍（和强一致性冲突）
- 快（理论上和强一致性也是冲突的，主要是由于要达到数据的一致性，然后又要在一定时间内响应）- 为什么快：因为采用的是基于消息传递（消息队列：顺序）的最终一致性协议（最终一致性可以容忍网络波动和单点故障），使得在一定时间内可以对客户端的请求作出一定响应，但注意：zookeeper更适用于读的比例高于写的比例的场景（如1:10）
- 在spring 体系中的常规应用：config & discovery；配置和服务发现
- 可应用在分布式锁（临时节点-session级别，断开后或session失效后则消失），此特性应也可用于微服务的服务管理
4、角色：
- Leader：领导者，负责写
- Follower：追随者，负责读
- Observer:基于zookeeper的设计目标，是要有极快的客户端响应速度，在故障恢复的时候需要重新选举，过多的节点参与选举会影响响应速度；而此角色是不参与投票的。故不会影响故障恢复的200ms目标