本文共 4138 字，大约阅读时间需要 13 分钟。

1.ZooKeeper是怎么保证事务的顺序一致性的？

ZooKeeper采用了递增的事务id来标识，所有的proposal（提议）都在被提出的时候加上了zxid，当产生proposal的时候，会根据数据库的两阶段过程，首先向其他的server发出事务执行请求，如果超过半数的机器都能够执行成功，那么会开始执行

 

ZooKeeper如何选取主leader的？

当leader崩溃或者leader失去大多数的follower，支持ZooKeeper进入恢复模式

 

ZooKeeper中的znode类型有四种：持久化节点     持久化顺序节点    临时节点   临时顺序节点

 

ZooKeeper的通知机制

client端会对某个znode建立一个watcher事件，当znode发生变化时，这些client会收到ZooKeeper的通知，然后client可以根据变化来做出业务上的改变

      工作机制： 1）客户端注册watcher

                          2）服务端处理watcher

                          3）客户端回调watcher

 

ZooKeeper是什么框架？

    一个开源的分布式协调服务

 

ZooKeeper保证了分布式一致性的特性：

     1）顺序一致性

     2）原子性

      3）最终一致性

     4）有序性：每个更新都有唯一的时间戳（zxid），读请求只会相对于更新有序，也就是读请求的返回结果中会带有最新的zxid

 

ZooKeeper对节点的watch监听通知是永久的吗？

不是，一个watch事件是一个一次性的触发器，当设置了watch的数据发生了改变的时候，则服务器将这个改变发送给设置了watch的客户端，以便通知它们

如果服务端变动频繁，而监听的客户端很多的情况下，每次变动都要通知所有的客户端，这太消耗性能了

一般客户端执行getData，如果节点A发生了变更或删除，客户端会得到它的watch时间，但是之后节点A又发生了变化，而客户端没有设置watch时间，就不再给客户端发送

实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可

 

部署方式？集群中的角色有哪些？集群最少要几台机器？

单机，集群      有leader，follower   最低3台，保证奇数，为了选举算法

过半存活即可用

 

机器中为什么会有master；

在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行master选举。

 

Zookeeper文件系统

Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。

 

zk的命名服务（文件系统）

命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

 

 

 

 

Zookeeper工作原理（ZAB）

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

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

Zab 协议的特性：

1）Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。 2）Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。

 

 

 

 

 

Zab 协议实现的作用

1）使用一个单一的主进程（Leader）来接收并处理客户端的事务请求（也就是写请求），并采用了Zab的原子广播协议，将服务器数据的状态变更以 事务proposal （事务提议）的形式广播到所有的副本（Follower）进程上去。

 

2）保证一个全局的变更序列被顺序引用。

Zookeeper是一个树形结构，很多操作都要先检查才能确定是否可以执行，比如P1的事务t1可能是创建节点"/a"，t2可能是创建节点"/a/bb"，只有先创建了父节点"/a"，才能创建子节点"/a/b"。

为了保证这一点，Zab要保证同一个Leader发起的事务要按顺序被apply，同时还要保证只有先前Leader的事务被apply之后，新选举出来的Leader才能再次发起事务。

 

3）当主进程出现异常的时候，整个zk集群依旧能正常工作

 

Zab协议原理

Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

• 发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。

• 同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。

• 广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。

 

Zab 协议如何保证数据一致性

假设两种异常情况：

1、一个事务在 Leader 上提交了，并且过半的 Folower 都响应 Ack 了，但是 Leader 在 Commit 消息发出之前挂了。 2、假设一个事务在 Leader 提出之后，Leader 挂了。

要确保如果发生上述两种情况，数据还能保持一致性，那么 Zab 协议选举算法必须满足以下要求：

Zab 协议崩溃恢复要求满足以下两个要求：

1）确保已经被 Leader 提交的 Proposal 必须最终被所有的 Follower 服务器提交。 2）确保丢弃已经被 Leader 提出的但是没有被提交的 Proposal。

根据上述要求

Zab协议需要保证选举出来的Leader需要满足以下条件： 1）新选举出来的 Leader 不能包含未提交的 Proposal 。 即新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点。 2）新选举的 Leader 节点中含有最大的 zxid 。 这样做的好处是可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作。

Zab 如何数据同步

1）完成 Leader 选举后（新的 Leader 具有最高的zxid），在正式开始工作之前（接收事务请求，然后提出新的 Proposal），Leader 服务器会首先确认事务日志中的所有的 Proposal 是否已经被集群中过半的服务器 Commit。

2）Leader 服务器需要确保所有的 Follower 服务器能够接收到每一条事务的 Proposal ，并且能将所有已经提交的事务 Proposal 应用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过啦并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中。

 

leader选举流程？

服务器启动时期的Leader选举

1.每个服务器发送一个投票(SID,ZXID)

其中sid是自己的myid，初始阶段都将自己投为Leader。

2.接收来自其他服务器的投票。

集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

3.处理投票

针对每个投票都按以下规则与自己的投票PK，PK后依据情况是否更新投票，再发送给其他机器。

• a.优先检查ZXID，ZXID较大者优先为Leader
• b.如果ZXID相同，检查SID，SID较大者优先为Leader

5.统计投票

每次投票后，服务器统计所有投票，判断是否有过半的机器收到相同的投票，如果某个投票达到一半的要求，则认为该投票提出者可以成为Leader。

6.改变服务器状态

一旦确定了Leader，每个服务器都更新自己的状态，Leader变更为Leading，Follower变更为Following

正常情况下一旦选出一个Leader则一直会保持，除非Leader服务器宕掉，则再进行重新选举。

服务器运行时期的Leader选举

1.变更状态

当Leader宕机后，余下的所非Observer的服务器都会将自己的状态变更为Looking，然后开启新的Leader选举流程。

2.每个服务器发出一个投票。

生成(SID,ZXID)信息，注意运行期间的ZXID可能是不同的，但是在投票时都会将自己投为Leader，然后发送给其他的服务器。

3.接收来自各个服务器的投票

与启动时过程相同

4.处理投票

与启动时过程相同

5.统计投票

与启动时过程相同

6.改变服务器状态

与启动时过程相同

 

 

ZooKeeper的使用场景：

  1.分布式协调

          假如A系统发送请求到消息队列，然后B系统消费该消息。A系统通过在发送请求后在ZooKeeper上对某个节点的值注册一个监听器，这样的话当B系统处理完后就去修改ZooKeeper上的那个节点的值，A系统就能收到通知，也就解决了分布式协调的问题

  2.分布式锁

        一台机器收到了请求之后先去ZooKeeper上获取一把分布式锁，也就是创建一个znode，这时如果另一个机器也尝试去创建znode是创建不了的，也就是获取不了分布式锁，直到第一台机器释放分布式锁，删除znode后该机器才能创建znode

 

 

转载地址：https://blog.csdn.net/qq_40058686/article/details/104420214 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！