一致性，可用性，分区容错性，不可兼得。
在分布式环境里，网络丢包延迟肯定会发生，所以分区容错性是必须要报保证的。只能在CA之间取舍。zookeeper选择了CP，eureka选择了AP。
是对CAP理论中C和A权衡的结果。适当牺牲一部分可用性和强一致性，来达到最终一致性。
基本可用，意思不是不可用，而是允许牺牲部分可用性。如，牺牲部分响应时间，或者进行降级。
软状态，即允许一定时间内的数据不一致。
最终一致性，即经过一定时间后，系统中的数据最终一致。而不用保证数据实时一致。
投票阶段
1.协调者询问各个参与者预提交事务
2.各个参与者开始执行事务，但不提交，将是否可执行返回给协调者
提交阶段
1.协调者根据是否所有参与者都能成功执行事务，如果可以，告知参与者提交事务，否则告知参与者回滚
2.参与者根据收到的消息，进行提交事务或者回滚事务
二阶段提交的问题。存在单点故障，同步阻塞，数据不一致。
在二阶段提交基础上增加了cancommit阶段，避免不必要的事物执行与回滚操作，并引入参与者超时机制，即在docommit阶段如果收取协调者消息超时进行自动提交，以避免资源锁定。
具体来说分为三个阶段
cancommit阶段：
1.协调者向参与者发送cancommit请求
2.参与者恢复yes or no
3.如果所有参与者回复yes，那么进入下一个阶段preCommit
precommit阶段
1.协调者向所有参与者发送precommit请求
2.参与者进行事务，占用资源，但不提交，并将执行结果反馈给协调者
3.协调者根据参与者反馈，如果存在反馈为no，则向所有参与者发送abort请求。否则进入下一阶段
docommit阶段
1.协调者向所有参与者发送事务commit通知
2.参与者提交事务，释放资源，并反馈给协调者
docommit阶段如果没有收到协调者的commit信息，那么该参与者会自动提交信息，以避免资源被长久锁定
三阶段提交解决了单点问题：如果docommit阶段没有收到，会自动提交事务。解决同步阻塞问题（通过引入cancommit）。不过依然存在数据不一致问题（docommit阶段，协调者向部分参与者发送abort信息然后挂掉，导致另外的参与者提交事务，造成数据不一致）
ZAB协议ZAB是为分布式协调服务zookeeper专门设计的一种支持崩溃服务的一致性协议。该协议实现了一种主从复制架构来保持集群中各个副本之间的数据一致性。
zookeeper面临两个问题：
1.数据更新如何从主节点更新到从节点
2.leader服务器失效后怎么处理
为此ZAB协议设计了两种模式：消息广播模式，崩溃恢复模式。
zookeeper分为server和client.client可以在所有server节点执行读操作，client可以在任何server发起写操作，非leader将会将此请求转发给leader节点，zookeeper使用简化版的二阶段提交来保证节点的事务一致性。
ZXID
64位的事务ID，前32位是纪元号，每次换主+1，后32位是计数器，每次事务+1.从而保证全局唯一。
history queue
每个follower都有一个FIFO的队列来存放事务请求，保证事务的顺序
可靠提交由ZAB的事务一致性协议保证，全局有序靠TCP协议保证，因果有序由follower的历史队列（history queue）保证
1.广播模式
消息广播模式其实是个简化版的二阶段提交，通常二阶段提交要搜集所有参与者的反馈。而zookeeper将参与者分为follower和Observer，只搜集超过一半follower的反馈就进行了提交，从而提高更新效率。
具体来说：
1.leader将客户端的request转化为一个proposal(提议)，生成ZXID
2.leader发送该提议给所有follower
3.每个follow将该事务保存到自己的FIFO的队列，并发送ack给leader
4.leader若收到半数以上的follower的ack反馈，则向所有follower发送commit
5.follow节点收到commit请求，会对照本地history queue 看该zxid是不是最小的，如果不是，则等待。如果是，提交该事务。
2.崩溃恢复模式
有选举-发现-同步-广播，四个阶段
如果leader挂了，所有节点由leading,following状态改为looking状态，此时停止对外服务。开始进行选举
1.选举，选出集群中具有最大zxid的点作为潜在的leader
2.发现，follow与潜在的leader进行通信，如果发现超过法定的follow同意，则潜在的leader将epoll+1,开始新纪元
3.同步，集群间进行数据同步，保证集群中各个节点事务一致
4.广播，恢复到广播模式，开始接受客户请求
