分布式一致性算法03 ZAB协议
ZAB（Zookeeper Atomic Broadcast）协议是为Apache Zookeeper框架设计的一致性协议。它主要用来确保分布式系统中的数据一致性，特别是在Zookeeper这样的分布式协调服务中。ZAB协议具有以下特点：
原子广播：ZAB协议保证了所有事务请求的顺序性和一致性，即客户端对Zookeeper的写请求要么被完全应用，要么完全不应用，不会出现中间状态。
主从架构：在ZAB协议中，有一个主服务器（Leader）负责处理所有事务请求，其他服务器作为从服务器（Follower）接收并复制Leader的数据。
高可用性：如果Leader发生故障，ZAB协议能够通过选举机制快速选出新的Leader，保证系统的持续可用性。
在ZAB协议中，Leader选举是确保集群中有一个单一的领导者来处理所有事务的关键过程。以下是ZAB协议中Leader选举的步骤和示例：
初始化：
集群中的每个服务器（Server）启动时，都处于“Looking”状态，即寻找Leader状态。
投票：
每个处于“Looking”状态的服务器都会发送投票（Vote）给其他服务器，尝试将自己选举为Leader。投票包含服务器的ID（myid）和事务ID（zxid）。
收集选票：
每个服务器在接收到投票后，会比较发送者的zxid和自己的zxid。如果发送者的zxid更大，或者两者zxid相同但发送者的myid更大，则接受投票并更新自己的投票信息。
确定Leader：
如果某个服务器获得了超过半数的投票，它就认为自己被选举为新的Leader，并切换到“Leading”状态。
同步：
新Leader会与集群中的其他服务器（Follower）进行数据同步，确保所有Follower的数据与Leader一致。
广播：
一旦数据同步完成，Leader开始接收客户端的事务请求，并将这些事务广播给所有Follower。
Leader选举示例：
假设我们有一个Zookeeper集群，包含5个服务器，每个服务器的ID分别是1, 2, 3, 4, 5。启动时，所有服务器都处于“Looking”状态。
初始化：
服务器1, 2, 3, 4, 5开始寻找Leader，并发送投票请求，每个服务器的投票都是投给自己。
投票：
假设服务器1的zxid是100，服务器2的zxid是99，服务器3, 4, 5的zxid都是98或更低。
服务器1发送投票请求（zxid=100, myid=1）。
收集选票：
服务器2, 3, 4, 5接收到服务器1的投票请求，比较zxid后发现1的zxid最大，因此它们将自己的投票投给服务器1。
确定Leader：
服务器1收到超过半数（3个）的投票，包括自己的投票，因此它认为自己被选举为Leader，并切换到“Leading”状态。
同步：
服务器1开始与服务器2, 3, 4, 5进行数据同步，确保所有Follower的数据与自己的数据一致。
广播：
数据同步完成后，服务器1作为Leader开始接收客户端的事务请求，并将这些事务以事务Proposal的形式广播给所有Follower。
Follower处理：
Follower接收到Leader的事务Proposal后，会将Proposal写入本地日志，并在大多数Follower确认后，Leader会指示Follower提交事务。
通过这个选举过程，ZAB协议确保了集群中有一个单一的Leader来处理所有的写请求，从而保证了数据的一致性。如果Leader发生故障，集群会重新进行选举过程，选择一个新的Leader。
ZAB协议的工作流程示例：
假设我们有一个由五台服务器组成的Zookeeper集群，其中一台服务器被选举为Leader，其余四台为Follower。
客户端请求：
客户端向集群发送写请求，比如创建一个Znode。
事务提案：
Leader接收到客户端的请求后，会生成一个事务提案（Proposal），并分配一个全局唯一的事务ID。
广播提案：
Leader将事务提案发送给所有Follower，要求它们复制这个提案。
Follower投票：
Follower接收到提案后，会根据自身的数据状态进行投票，并将投票结果发送回Leader。
Leader决定：
当Leader收到超过半数Follower的同意投票后，它会做出决定，并将决定结果通知所有Follower。
提交或回滚：
如果提案被接受，Leader会指示所有Follower提交这个事务，更新它们的状态。如果提案被拒绝或Leader在等待投票结果时发生故障，事务将被回滚。
故障恢复：
如果Leader在处理过程中发生故障，Follower会进入新一轮的Leader选举，并从最新的状态开始同步。
客户端响应：
一旦事务被提交，Leader会向客户端返回操作结果，客户端根据结果进行相应的处理。
ZAB协议的关键点：
顺序一致性：ZAB协议保证了客户端请求的顺序性，即在任意时刻，客户端的请求都会按照某种顺序被处理。
可靠性：即使在部分服务器宕机的情况下，ZAB协议也能够保证系统的可靠性和数据的一致性。
实时性：ZAB协议通过快速的Leader选举和事务处理机制，保证了系统的实时性。
ZAB协议是Zookeeper能够提供高可用性和一致性的关键，它使得Zookeeper成为了分布式系统中广泛使用的协调服务。
在ZAB协议中，Epoch和ZXID是两个关键的概念，它们共同确保了集群状态的一致性。
ZXID（事务ID）
定义：ZXID是一个64位的数字，用于唯一标识Zookeeper中的每个事务。
组成：ZXID的高32位表示Epoch，低32位表示事务计数器（xid）。
作用：
确保事务的全局顺序性。每个事务都有一个唯一的ZXID，保证了事务在所有服务器上的处理顺序一致。
通过比较ZXID，服务器可以确定事务的先后顺序，以及是否已经处理过某个事务。
Epoch（纪元）
定义：Epoch是ZXID的高32位，表示领导者的任期编号。每次新的领导者被选举出来时，Epoch都会增加。
作用：
标识领导者的任期。不同的Epoch代表不同的领导者任期，确保了领导者的唯一性。
处理网络分区和领导者故障恢复的情况。当发生分区或领导者故障时，新的领导者会具有更高的Epoch，从而确保了新的领导者具有最新的状态。
确保集群状态一致性的机制：
领导者选举：
在选举过程中，节点会根据ZXID和Epoch来决定投票。拥有更高Epoch和ZXID的节点更有可能被选举为领导者。
事务处理：
领导者在处理事务时，会为每个事务分配一个新的ZXID，确保每个事务都是顺序处理的。
数据同步：
领导者会将事务日志同步给跟随者。跟随者接收到事务日志后，会按照ZXID的顺序进行处理，确保了数据的一致性。
领导者故障恢复：
当领导者发生故障时，新的领导者会从跟随者中选举出来，并且具有更高的Epoch。这确保了新的领导者能够覆盖旧领导者的状态，维持集群状态的一致性。
跟随者的同步状态：
跟随者在接收到领导者的同步请求时，会根据Epoch和ZXID来确定是否接受同步。如果领导者的Epoch更高，跟随者会更新自己的状态以匹配领导者。
提案的顺序性：
由于ZXID的单调递增特性，保证了提案（Proposal）的顺序性，即使在网络分区的情况下，也能够维持事务的全局顺序。
通过这些机制，ZAB协议能够在分布式环境中有效地维护集群状态的一致性，即使在网络分区和领导者故障的情况下也能够正确地进行恢复和同步。