Zookeeper

概念：分布式协调框架，帮别的集群选举主节点，帮自己选举节点（面试重点）

CAP原则【理解※】：

Avaliability：可用性 【在有效的时间返回结果】

Consistency：一致性 【在集群中任何一个节点获取数据都是相同的】

Partition Tolerance：分区容错性 【集群部署】

只能同时保证两种特性

AC：单击应用

CP：集群部署，数据一致性 银行【金融】

AP：可用，分区容错 秒杀，不要求用户看到的数据实时一致【电商查询】

BASE理论

BA：基本可用-保留基本功能不影响正常运作

S：软状态一致性-当写入集群达到一半即达到软状态一致性

E：最终一致性-最终能达到一致性即可

最终一致性：

读：从某个节点获取的数据可能不是最新的，但是如果需要修改这个数据，必须获取最新数据。比如12306抢票系统。

写：当写入集群节点大于二分之一，就认为达到软状态一致性，最终可以通过广播等机制实现最终一致性。

拜占庭将军问题！

Paxos算法

活锁的产生是由于偶数个议员，33对立造成的。

解决方案：

1、使用奇数台服务器，但是奇数台有一台宕机依然为偶数台也是不行的。

2、使用有主模型，所有的提议都只能有总统来发出。

总统挂掉以后怎么办？快速选择总统？

1. 找PID最接近公共PID的议员，但是不能大于公共PID【因为不是法令】。

2. 如果有多个议员PID相同，那么就选择MYID最大的那个【议员3、议员4=>议员4】

如果网络波动就会出现脑裂出现多个主节点，最终合并选主必须过半原则。

两个主需要看那边议员多谁就做最新的总统。

节点越多业务能力越强，但是选主越慢！

-> 减少选举参与者 ->观察者Observer

Raft算法

角色：Leader、Follower、Candidate

Term：版本朝代

在换朝代只会进行重新的一次选举，注意：选举拉票也需要总人数过半才可以成为新的总统Leader。【只要出现新的候选人就会直接换朝代号】

如果出现分区的情况，在合并的的时候要看Leader的朝代版本号Term；

日志复制：

主要用户保证节点的一致性，这阶段所做的操作时为了一致性与高可用。

Leader选举首先通过随机倒计时【选举超时】150ms-300ms之间，先倒计时完的Follower成为Candidate，然后进行拉票，当拉票过半即可成为Leader。

当Leader接收到事务（更新操作）后，经过Leader先存放到日志中，然后将该Entry同步到其他Follower，当Leader收到过半Follower的ACK（签收）信息后，将日志设置为已提交并追加到本地磁盘中，并通知其他客户端将Entry存到自己的磁盘中。完成数据一致性。

选主

同时启动 myid最大成为主节点

依次启动 过半第一个节点将成为主节点

Zab协议

概念

Zab协议的全称为Zookeeper Atomic Broadcast 【Zookeeper原子广播】

ZAB协议是为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议。ZAB借鉴Paxos算法。

Zookeeper就是通过Zab协议来保证分布式事务的最终一致性的。

阶段&原理

Zab协议的三个阶段：发现->同步->广播

协议核心

定义了事务请求的处理方式：

所有的请求必须由全局唯一的Leader服务器协调处理，其他则是Follower服务器

Leader服务器负责将一个客户端事务请求，转换成一个事务Proposal，并分发到所有Follower服务器

分发之后Leader服务器需要等待所有的Follower服务器的反馈【ACK请求】，在Zab协议中，只要超过一半的反馈之后，Leader会再次向所有的Follower发送Commit消息。

协议内容

包含两种基本模式：1、崩溃恢复-数据恢复；2、消息广播-原子广播；