1.修复 ZooKeeper 数据视不一致
2.ZK currentEpoch&acceptedEpoch
3.Zookeeper 理论基础

修复 ZooKeeper 数据视不一致

       ZooKeeper是一个开源的分布式系统协调中间件，常用于实现选主、pub/sub模式、分布式锁等功能。ZooKeeper的核心是Zab协议，即ZooKeeper原子广播协议。gdb工具源码下载Zookeeper通过ZKDatabase保存数据，数据结构是DataTree，它维护了一个路径到DataNode的哈希表。Snapshot是DataTree序列化后保存在磁盘的一系列文件，而启动时Zookeeper会使用磁盘上的Snapshot在内存中重建DataTree。

       Zookeeper的客户端在进行读操作时，会从本地服务器获取数据，与Raft模型中的非领导者节点不同。每个事务都有一个zxid标识，它是全局唯一的位整数，由位的android 彩信源码Epoch和位的自增ID（Counter）组成。每次事务提交，Counter加1，当有新成员当选领导者时，Epoch加1。当zxid溢出时，会触发选举并重置为0。

       ZooKeeper提供了一个类似文件系统的API，用于组织和操作Znode。安卓商业源码Znode以树状结构排列，并支持create、delete、getData和setData等操作。

       ZooKeeper的一致性保证属于ordered sequential consistency，即在写操作中保证线性一致性，在读操作中只保证顺序一致性。这意味着，可爱网站源码客户端A更新ZnodeZ后，客户端B读取Z时，B可能无法立即读到最新值，但在读到最新值后，B不应该再读到任何过期数据。

       在解决服务在ZooKeeper节点A上更新数据后，一段时间内读取到过期数据的问题时，发现了一个名为ZOOKEEPER-的团购网站源码 .net类似问题。该问题在新版本的ZooKeeper中已经修复。通过分析ZooKeeper的工作过程，我们可以了解到其Zab协议包括选举、恢复和广播三个阶段。

       每个成员在启动时会进入选举状态，选出lastZxid最大的节点作为领导者。领导者进入恢复阶段，首先通过选票找到当前领导者，然后与领导者同步已提交事务，确保本地数据副本与领导者一致。同步策略包括DIFF Sync、TRUNC Sync和SNAP Sync。DIFF Sync通过发送一系列的PROPOSAL和COMMIT消息进行数据同步。TRUNC Sync通过删除比leader更大的事务进行同步。SNAP Sync则通过发送快照进行数据恢复。在恢复完成后，领导者向follower发送NEWLEADER消息，等待多数follower确认后，发送UPTODATE消息，follower接收到UPTODATE并确认后开始对外提供服务。

       当follower在接收到NEWLEADER消息后，ACK NEWLEADER之前需要持久化所有未提交的DIFF Sync Proposal。这样可以确保在领导者永久下线并最终导致客户端认为已提交请求在同步过程中被丢弃的情况下，数据一致性得到保证。通过这种方式，ZooKeeper成功修复了ZOOKEEPER-问题。

       在理解了问题的原因和修复方式后，我司通过将关键的patch回滚到v3.5.9版本，并从3.4.升级到3.5.9来解决实际问题。经过一系列的调试和修正，最终解决了Socket关闭导致的单测失败问题，完成了对ZOOKEEPER-问题的修复及版本回滚。

       总结来看，分布式系统的设计和维护充满挑战，需要细致入微的调试和深入的理解。通过这次经验，我深刻认识到分布式系统的复杂性和工作背后的辛勤付出，同时也对维护和优化分布式系统环境的重要性有了更深刻的认识。

ZK currentEpoch&acceptedEpoch

       åœ¨åšå¤šæœºæˆ¿kafka切ZK演练时发现,当原集群的zk节点加入新集群时,出现报错

        Leaders epoch, 6 is less than accepted epoch, 9

        查看/data/zookeeper/data/version-2目录下确实有2个文件,分别是

        acceptedEpoch、currentEpoch,这2个文件里的值都是9

        这是为什么呢?这两个文件是做什么的?

        这两个文件分别反映了指定的server进程已经看到的和参与的epoch number。尽管这些文件不包含任何应用级别的数据，但他们对于数据一致性来说很重要，决定了集群的选主能否成功.

       .atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-

        这两个变量主要是为了解决集群失败恢复的场景

        As mentioned, the implementation up to version 3.3.3 has not included epoch variables acceptedEpoch and currentEpoch. This omission has generated problems [5]

        (issue ZOOKEEPER- in Apache’s issue tracking system) in a production version

        and was noticed by many ZooKeeper clients. The origin of this problem is at the beginning of Recovery Phase (Algorithm 4 line 2), when the leader increments its epoch

        (contained in lastZxid) even before acquiring a quorum of successfully connected followers (such leader is called false leader ). Since a follower goes back to FLE if its

        epoch is larger than the leader’s epoch (line ), when a false leader drops leadership

        and becomes a follower of a leader from a previous epoch, it finds a smaller epoch (line

        简单来说就是: 以前是不区分acceptedEpoch 和 currentEpoch的，以前epoch是直接从zxid中前位里提取的。但这会导致一个问题：假设有三个服务器s1, s2, s3. 集群s1和s2取得联系，且s1为leader，s3为LOOKING:

        s2重启，加上s3的选票，将s3选为leader

        s3把自己当做leader，且epoch+1，但无法与其它server取得联系。此时s1还是认为自己是leader(后文会问为什么)。

        s2无法与s3取得联系，同时收到s1的LEADING信息，便回到s1的旧集群里

        s3无法与他人取得联系，退出leadership，回到FLE，并收到旧集群leader s1的消息，便作为follower也回到旧集群里

        s3作为follower发现自己的epoch比旧leader的epoch还大，便又回到FLE

        之后s3就不断在4和5之间徘徊，不断在FLE阶段和RECOVER阶段循环。

        至于为什么s1自认为自己是leader, 是因为leader有一个缓存时间导致leader不会因为某些瞬时故障而结束自己的任期.

        这个缓存时间的原理是:心跳包

        在心跳包以内leader1检测不到leader2和leader3的learnHandler线程死亡,因而leader状态保持有效,仅仅是状态表示标识,不会影响写操作,因为写操作会要求半数以上节点响应,而这个时间端这个要求是不满足的.

        那么acceptedEpoch和currentEpoch是怎么解决故障恢复问题的呢?

        if (newEpoch > self.getAcceptedEpoch()) {

        wrappedEpochBytes.putInt((int) self.getCurrentEpoch());

        self.setAcceptedEpoch(newEpoch);

        } else if (newEpoch == self.getAcceptedEpoch()) {

        // since we have already acked an epoch equal to the leaders, we cannot ack

        // again, but we still need to send our lastZxid to the leader so that we can

        // sync with it if it does assume leadership of the epoch.

        // the -1 indicates that this reply should not count as an ack for the new epoch

        wrappedEpochBytes.putInt(-1);

        } else {

        throw new IOException("Leaders epoch, "

        + newEpoch

        + " is less than accepted epoch, "

        + self.getAcceptedEpoch());

        直接报错,强制不允许大于leader的epoch的节点加入集群

Zookeeper 理论基础

        ZooKeeper 由雅虎研究院开发，后来捐赠给了 Apache。ZooKeeper 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 Paxos 算法的ZAB 协议完成的。其主要功能包括：配置维护、域名服务、分布式同步、集群管理等。

        zookeeper 的官网： mit 功能。具体看下面的描述。

        Paxos 算法的 3PC 执行过程划分为三个阶段：准备阶段 prepare、接受阶段 accept，与提交阶段 commit。

        若提案者接收到的反馈数量超过了半数，则其会向外广播两类信息：

        2PC 与 3PC 的区别是，在提案者接收到超过半数的表决者对于 parepare 阶段的反馈后，其会向所有表决者发送真正的提案 proposal。当表决者接受到 proposal 后就直接将其同步到了本地，不用再等待 commit 消息了。

        那么，为什么不直接使用 2PC，而要使用 3PC 呢？是因为 2PC 中存在着较多的弊端（这里就不再展开来说了）。所以很多 Paxos 工业实现使用的都是 3PC 提交。但 2PC 提交的效率要高于 3PC 提交，所以在保证不出问题的情况下，是可以使用 2PC 提交的。

        前面所述的Paxos 算法在实际工程应用过程中，根据不同的实际需求存在诸多不便之处， 所以也就出现了很多对于基本 Paxos 算法的优化算法，以对 Paxos 算法进行改进，例如，Multi Paxos、Fast Paxos、EPaxos。

        例如，Paxos 算法存在“活锁问题”，Fast Paxos 算法对 Paxos 算法进行了改进：只允许一个进程提交提案，即该进程具有对 N 的唯一操作权。该方式解决了“活锁”问题。

        ZAB ，Zookeeper Atomic Broadcast，zk 原子消息广播协议，是专为 ZooKeeper 设计的一种支持崩溃恢复的原子广播协议，在 Zookeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。

        Zookeeper 使用一个单一主进程来接收并处理客户端的所有事务请求，即写请求。当服务器数据的状态发生变更后，集群采用 ZAB 原子广播协议，以事务提案 Proposal 的形式广播到所有的副本进程上。ZAB 协议能够保证一个全局的变更序列，即可以为每一个事务分配一个全局的递增编号 xid。

        当 Zookeeper 客户端连接到 Zookeeper 集群的一个节点后，若客户端提交的是读请求， 那么当前节点就直接根据自己保存的数据对其进行响应；如果是写请求且当前节点不是Leader，那么节点就会将该写请求转发给 Leader，Leader 会以提案的方式广播该写操作，只要有超过半数节点同意该写操作，则该写操作请求就会被提交。然后 Leader 会再次广播给所有订阅者，即 Learner，通知它们同步数据。

        ZAB 协议是 Paxos 算法的一种工业实现算法。但两者的设计目标不太一样。ZAB 协议主要用于构建一个高可用的分布式数据主从系统，即 Follower 是 Leader 的从机，Leader 挂了， 马上就可以选举出一个新的 Leader，但平时它们都对外提供服务。而 Fast Paxos 算法则是用于构建一个分布式一致性状态机系统，确保系统中各个节点的状态都是一致的。

        另外，ZAB 还使用 Google 的 Chubby 算法作为分布式锁的实现，而 Google 的 Chubby 也是 Paxos 算法的应用。

        zk 集群对于事务请求的处理是 Fast Paxos 算法的体现，即只允许 Leader 提出提案。其属于 3PC 提交。

        但 Leader 选举是 Paxos 算法的体现，因为 Leader 宕机后，所有 Follower 均可提交提案， 它们在最初都是“我选我”。其属于 2PC 提交。

        为了避免 Zookeeper 的单点问题，zk 也是以集群的形式出现的。zk 集群中的角色主要有以下三类：

        Learner：学习者，同步者。

        Learner = Follower + Observer

        QuorumPeer = Participant = Leader + Follower

        在 ZAB 中有三个很重要的数据：

        ZAB 协议中对zkServer 的状态描述有三种模式。这三种模式并没有十分明显的界线，它们相互交织在一起。

        zk 集群中的每一台主机，在不同的阶段会处于不同的状态。每一台主机具有四种状态。

        在集群启动过程中，或 Leader 宕机后，集群就进入了恢复模式。恢复模式中最重要的阶段就是 Leader 选举。

        A、serverId

        这是zk 集群中服务器的唯一标识，也称为 sid，其实质就是 zk 中配置的 myid。例如， 有三个 zk 服务器，那么编号分别是 1,2,3。

        B、 逻辑时钟

        逻辑时钟，Logicalclock，是一个整型数，该概念在选举时称为 logicalclock，而在选举结束后称为epoch。即 epoch 与 logicalclock 是同一个值，在不同情况下的不同名称。

        在集群启动过程中的 Leader 选举过程（算法）与 Leader 断连后的 Leader 选举过程稍微有一些区别，基本相同。

        A、集群启动中的 Leader 选举

        对于 Server1 而言，它的投票是(1, 0)，接收 Server2 的投票为(2, 0)。其首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是 Server1 更新自己的投票为(2, 0)，然后重新投票。对于 Server2 而言，其无须更新自己的投票，只是再次向集群中所有主机发出上一次投票信息即可。

        (4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息。对于 Server1、Server2 而言，都统计出集群中已经有两台主机接受了(2, 0)的投票信息，此时便认为已经选出了新的 Leader，即 Server2。

        (5) 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING。

        (6) 添加主机。在新的 Leader 选举出来后 Server3 启动，其想发出新一轮的选举。但由于当前集群中各个主机的状态并不是 LOOKING，而是各司其职的正常服务，所以其只能是以Follower 的身份加入到集群中。

        B、 宕机后的 Leader 选举

        在 Zookeeper 运行期间，Leader 与非 Leader 服务器各司其职，即便当有非 Leader 服务器宕机或新加入时也不会影响 Leader。但是若 Leader 服务器挂了，那么整个集群将暂停对外服务，进入新一轮的 Leader 选举，其过程和启动时期的 Leader 选举过程基本一致。

        前面我们说过，恢复模式具有两个阶段：Leader 选举与初始化同步。当完成 Leader 选举后，此时的 Leader 还是一个准 Leader，其要经过初始化同步后才能变为真正的 Leader。

        具体过程如下：

        当集群中的 Learner 完成了初始化状态同步，那么整个 zk 集群就进入到了正常工作模式了。

        如果集群中的 Learner 节点收到客户端的事务请求，那么这些 Learner 会将请求转发给Leader 服务器。然后再执行如下的具体过程：

        Observer 数量并不是越多越好，一般与 Follower 数量相同。因为 Observer 数量的增多虽不会增加事务操作压力，但其需要从 Leader 同步数据，Observer 同步数据的时间是小于等于 Follower 同步数据的时间的。当 Follower 同步数据完成，Leader 的 Observer 列表中的Observer 主机将结束同步。那些完成同步的 Observer 将会进入到另一个对外提供服务的列表。那么，那些没有同步了数据无法提供服务的 Observer 主机就形成了资源浪费。

        所以，对于事务操作发生频繁的系统，不建议使用过多的 Observer。

        Leader 中保存的 Observer 列表其实有两个：

        all：包含所有 Observer。

        service：已经完成了从 Leader 同步数据的任务。service <= all。其是动态的。

        Leader 中保存的 Follower 列表其实也有两个：

        all：要求其中必须有过半的 Follower 向Leader 反馈ACK

        service：

        当集群正在启动过程中，或 Leader 崩溃后，集群就进入了恢复模式。对于要恢复的数据状态需要遵循三个原则。

        若集群中 Leader 收到的 Follower 心跳数量没有过半，此时 Leader 会自认为自己与集群的连接已经出现了问题，其会主动修改自己的状态为 LOOKING，去查找新的 Leader。

        而其它 Server 由于有过半的主机认为已经丢失了 Leader，所以它们会发起新的 Leader选举，选出一个新的 Leader。

        正常情况下，当 Leader 收到超过半数 Follower 的 ACKs 后，就向各个 Follower 广播COMMIT 消息，批准各个Server 执行该写操作事务。当各个Server 在接收到Leader 的COMMIT 消息后就会在本地执行该写操作，然后会向客户端响应写操作成功。

        但是如果在非全部 Follower 收到 COMMIT 消息之前 Leader 就挂了，这将导致一种后果：部分 Server 已经执行了该事务，而部分 Server 尚未收到 COMMIT 消息，所以其并没有执行该事务。当新的 Leader 被选举出，集群经过恢复模式后需要保证所有 Server 上都执行了那些已经被部分 Server 执行过的事务。

        当在 Leader 新事务已经通过，其已经将该事务更新到了本地，但所有 Follower 还都没有收到 COMMIT 之前，Leader 宕机了，此时，所有 Follower 根本就不知道该 Proposal 的存在。当新的 Leader 选举出来，整个集群进入正常服务状态后，之前挂了的 Leader 主机重新启动并注册成为了 Follower。若那个别人根本不知道的 Proposal 还保留在那个主机，那么其数据就会比其它主机多出了内容，导致整个系统状态的不一致。所以，该 Proposa 应该被丢弃。类似这样应该被丢弃的事务，是不能再次出现在集群中的，应该被清除。

        前面我们说过，无论是写操作投票，还是 Leader 选举投票，都必须过半才能通过，也就是说若出现超过半数的主机宕机，则投票永远无法通过。基于该理论，由 5 台主机构成的集群，最多只允许 2 台宕机。而由 6 台构成的集群，其最多也只允许 2 台宕机。即，6 台与5 台的容灾能力是相同的。基于此容灾能力的原因，建议使用奇数台主机构成集群，以避免资源浪费。

        但从系统吞吐量上说，6 台主机的性能一定是高于 5 台的。所以使用 6 台主机并不是资源浪费。

        对于一个高可用的系统，除了要设置多台主机部署为一个集群避免单点问题外，还需要考虑将集群部署在多个机房、多个楼宇。对于多个机房、楼宇中集群也是不能随意部署的， 下面就多个机房的部署进行分析。

        在多机房部署设计中，要充分考虑“过半原则”，也就是说，尽量要确保 zk 集群中有过半的机器能够正常运行。

        在生产环境下，三机房部署是最常见的、容灾性最好的部署方案。三机房部署中要求每个机房中的主机数量必须少于集群总数的一半。

        zk 官方没有给出较好的双机房部署的容灾方案。只能是让其中一个机房占有超过半数的主机，使其做为主机房，而另一机房少于半数。当然，若主机房出现问题，则整个集群会瘫痪。

        CAP 定理又称 CAP 原则，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

        对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但其并不能同时保证一致性与可用性。CAP 原则对于一个分布式系统来说，只可能满足两项，即要么 CP，要么 AP。

        BASE 是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写。

        BASE 理论的核心思想是：即使无法做到实时一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

        基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

        损失响应时间：

        损失功能：

        软状态，是指允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种灰度状态，过渡状态。

        最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的一致性。

        从达到一致性的时间角度来划分，可以分为：

        单从客户端访问到的内容角度来划分，可以分为：

        zk 遵循的是 CP 原则，即保证了一致性，但牺牲了可用性。体现在哪里呢？

        当 Leader 宕机后，zk 集群会马上进行新的 Leader 的选举。但选举时长一般在 毫秒内，最长不超过 秒，整个选举期间 zk 集群是不接受客户端的读写操作的，即 zk 集群是处于瘫痪状态的。所以，其不满足可用性。

        这里说的zk可能会引发脑裂，是指的在多机房部署中，若出现了网络连接问题，形成多个分区，则可能会出现脑裂问题，可能会导致数据不一致。

        （1）情况一

        （2）情况二

        （5）情况五