ZAB协议
- ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议，实现分布式数据一致性
- 所有客户端的请求都是写入到Leader进程中，然后，由Leader同步到其他节点，称为Follower。在集群数据同步的过程中，如果出现Follower节点崩溃或者Leader进程崩溃时，都会通过Zab协议来保证数据一致性
ZAB协议的两种模式
ZAB协议包括两种基本的模式：消息广播和崩溃恢复
消息广播：
- 集群中所有的事务请求都由Leader节点来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower。
- 完成广播之后，Leader等待Follwer反馈，当有过半数的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit信息就是确认将之前的Proposal提交。
- Leader节点的写入是一个两步操作，第一步是广播事务操作，第二步是广播提交操作，其中过半数指的是反馈的节点数>=N/2+1，N是全部的Follower节点数量。
崩溃恢复
- 初始化集群，刚刚启动的时候
- Leader崩溃，因为故障宕机的时候
- Leader失去了半数的机器支持，与集群中超过一半的节点断连的时候
此时开启新一轮Leader选举，选举产生的Leader会与过半的Follower进行同步，使数据一致，当与过半的机器同步完成后，就退出恢复模式，然后进入消息广播模式。
整个ZooKeeper集群的一致性保证就是在上面两个状态之前切换，当Leader服务正常时，就是正常的消息广播模式；当Leader不可用时，则进入崩溃恢复模式，崩溃恢复阶段会进行数据同步，完成以后，重新进入消息广播阶段。
Zxid是Zab协议的一个事务编号，Zxid是一个64位的数字，其中低32位是一个简单的单调递增计数器，针对客户端每一个事务请求，计数器加1；而高32位则代表Leader周期年代的编号。
Leader周期（epoch），可以理解为当前集群所处的年代或者周期，每当有一个新的Leader选举出现时，就会从这个Leader服务器上取出其本地日志中最大事务的Zxid，并从中读取epoch值，然后加1，以此作为新的周期ID。高32位代表了每代Leader的唯一性，低32位则代表了每代Leader中事务的唯一性。
Zab节点的三种状态
- following：服从leader的命令
- leading：负责协调事务
- election/looking：选举状态
负载均衡策略有哪些
- 轮询法
将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
- 加权轮询法
不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
- 随机法
通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。
- 加权随机法
与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。
- 源地址哈希法
源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
- 最小连接数法
最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。
分布式系统的设计目标(分布式的好处)
- 可扩展性：通过对服务、存储的扩展，来提高系统的处理能力，通过对多台服务器协同工作，来完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。
- 高可用：单点不影响整体，单点故障指系统中某个组件一旦失效，会让整个系统无法工作
- 无状态：无状态的服务才能满足部分机器宕机不影响全部，可以随时进行扩展的需求。
- 可管理：便于运维，出问题能不能及时发现定位
- 高可靠：同样的请求返回同样的数据；更新能够持久化；数据不会丢失
