zookeeper

① 当zk作为dubbo的注册中心时，是怎么工作的？

• 服务提供者在初始化启动时，会在Zookeeper下的Dubbo节点下的服务节点下的providers节点下的节点创建一个子节点并写入URL，路径类似为 /dubbo/servicename/providers/ ，该路径下的所有子节点均为服务提供者。
• 此时这些子节点都为临时节点，因为临时节点的生命周期与客户端会话相关，所以一旦提供者所在的机器出现故障导致提供者无法提供服务，该临时节点就会自动从Zookeeper删除。
• 此时因为服务者，注册中心，消费者之间是长连接，注册中心能感知服务者宕机，会告知消费者。而监控中心是Dubbo服务治理体系中重要的一部分，它需要知道所有的服务提供者和消费者的变化情况 。所以它在启动时会在服务节点上注册一个watcher来监听子节点变化，路径为 /dubbo/servicename/ ，所以它也能感知服务提供者的宕机。
• 服务消费者的节点创建过程和提供者是一样的，而且也是临时结点。还有一个特性就是Zookeeper的节点结构设计，它以服务名和类型，也就是 /dubbo/servicename/类型 作为节点路径，符合Dubbo订阅和通知的需求，保证了以服务为粒度的变更通知，通知范围易于控制。所以即使服务提供者和消费者频繁变更，对Zookeeper的性能也不会造成多大影响。

② 简述ZAB协议以及Zookeeper?

2.1 zookeeper为分布式应用提供一个高效可靠的分布式协调服务器。zk通过zab协议来保证zk模式中数据的一致性。

• zk集群中的任何一台机器都可以响应客户端的读操作 ；
• zk将所有的数据都存储在内存中 ；
• zk中有三个角色，leader、follower、observer
  • leader是选举出来的角色，具有读写能力
  • follower具有读能力
  • observer只有读的能力，且不参与选举，也不参与过半写成功的策略，可以在不影响写的前提下提高集群读性能

2.2 zab协议是为了zk专门设计的一种支持奔溃回复的消息广播协议。 zab有两种模式：故障恢复模式和消息广播。

• 消息广播：
  • 只允许一个主进程接受客户事务请求并处理，即leader ；
  • leader接受请求后， 将事务请求转化成事务proposal ，并为follower创建一个队列， 并把该事务放入响应队列中 ，保证事务顺序性，并按顺序向其他节点广播提案 ；
  • follower接受到消息并保存到本地以后，向leader发送ack 确认；
  • 当leader收到一半以上follower的响应时，leader提交该提案 ；
• 故障恢复模式：
  • 当系统启动或者leader服务器出现故障等现象时，进入故障恢复模式，将会开启新的一轮选举；
  • leader会和过半的follower进行同步，使数据一致；
  • 数据同步以后，退出故障模式，进入消息广播模式；
  • 集群中的非leader节点如果收到客户的请求，会先将请求发送到leader服务器；

    

③ Zookeeper的某个机器挂了，整个集群如何处理？

看挂掉的是leader还是follower：

• 如果是leader，则进行新leader的选举；
• 如果是follower，还有其他节点可以提供服务，因为zookeeper集群中的数据每个节点上都有一份副本；

④ 简述ZK的fastleaderelection选举leader的算法

• 半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

• Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

选举的过程：

例如，有 id 为 1，2，3 三台机子，按顺序启动，第一台开启时，Zookeeper 的日志会报错，因为启动数量没有达到集 一半:有 id 为 1，2，3 三台机子，按顺序启动 1.启了两台，总共三台），数量多于一半，然 后根据 ID 的大小选出 Leader，则 2 号当选；2.3 号启动时，Leader 已经存在，则只能当小弟了。

⑤ zookeeper如何保证数据的一致性？

保证数据同步有两种情况：

• 第一种是重新选取leader之后的数据同步；
• 第二种是leader处理事务请求后与follower的数据同步 ；

具体流程：（其实就是zab的消息广播模式）

• 当leader收到请求后，将事务请求转化成事务proposal，由于leader为每一个follower创建一个队列，并把该事务放入响应队列中，保证事务的顺序性。之后在队列中顺序地向follower广播该提案。
• follower接收到提案后，以事务的形式写入本地日志中，并向leader发送ack。
• 当超过半数的follower向leader发送恢复，leader会向其他节点发送commit消息，同时leader提交该事务。

⑥ 简述Paxos算法

 Paxos算法需要解决的问题就是如何在一个可能发生机器宕机或网络异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致。

6.1 角色组成

Paxos由Acceptor、proposer和leaner三种角色组成 ：

• proposer负责提出提案 ；
• acceptor负责对提案裁决 ；
• leaner负责学习得到的提案 ；

为了避免单点故障，会有一个acceptor集合，proposer向该集合发送提案，acceptor集合中的每个成员都有可能同意该提案并且每个acceptor只能批准一个提案，当有一半以上的成员同意，则同意该提案。

6.2  Paxos算法过程

Paxos算法分为两个阶段： prepare阶段和accept阶段。

阶段一：prepare阶段

• Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求；
• 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案；

阶段二： accept阶段

• 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定；
• 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案；

6.3 learn三种学习策略

参考链接：https://blog.csdn.net/weixin_33943836/article/details/91731213