面试题--Dubbo、MQ、Zookeeper篇

面试题--Dubbo、MQ、Zookeeper篇

面试题--Dubbo篇

• Dubbo
• 1、说说一次Dubbo服务请求流程？
• 2、Dubbo工作原理
• 3、Dubbo支持哪些协议？
• 4、注册中心挂了，consumer还能不能调用provider？
• 5、怎么实现动态感知服务下线的呢？
• 6、Dubbo负载均衡策略？
• 7、Dubbo容错策略
• 8、Dubbo动态代理策略有哪些？
• 9、说说 Dubbo 与 Spring Cloud 的区别？
• 10、Zookeeper和Dubbo的关系
• MQ
• 1、为什么使用MQ
• 2、MQ有什么优缺点
• 3、Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别？
• 4、如何保证高可用的？
• 5、如何保证消息的可靠传输？如果消息丢了怎么办
• 6、如何保证消息的顺序性
• 7、 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
• 8、让你来设计一个消息队列，你会怎么设计
• zookeeper
• 1、说说zookeeper是什么？
• 2、Zookeeper有哪些应用场景？
• 3、说说Zookeeper的工作原理
• 4、请描述一下Zookeeper的通知机制是什么？
• 5、Zookeeper对节点的watch监听通知是永久的吗？
• 6、Zookeeper 集群中有哪些角色？
• 7、Zookeeper集群中Server有哪些工作状态？
• 8、 Zookeeper 集群中是怎样选举leader的？
• 9、Zookeeper 是如何保证事务的顺序一致性的呢？
• 10、ZooKeeper 集群中个服务器之间是怎样通信的？
• 11、ZooKeeper 分布式锁怎么实现的？
• 12、了解Zookeeper的系统架构吗？
• 13、Zookeeper为什么要这么设计？
• 14、你知道Zookeeper中有哪些角色？
• 15、你熟悉Zookeeper节点ZNode和相关属性吗？
• 16、请简述Zookeeper的选主流程
• 17、为什么Zookeeper集群的数目，一般为奇数个？
• 18、知道Zookeeper监听器的原理吗？
• 19、说说Zookeeper中的ACL 权限控制机制
• 20、Zookeeper 有哪几种几种部署模式？
• 21、Zookeeper集群支持动态添加机器吗？
• 22、描述一下 ZAB 协议
• 23、ZAB 和 Paxos 算法的联系与区别？
• 24、ZooKeeper 宕机如何处理？
• 25、 描述一下 ZooKeeper 的 session 管理的思想？
• 26、ZooKeeper 负载均衡和 Nginx 负载均衡有什么区别？
• 27、说说ZooKeeper 的序列化
• 28，在Zookeeper中Zxid 是什么，有什么作用？
• 29、讲解一下 ZooKeeper 的持久化机制
• 30、Zookeeper选举中投票信息的五元组是什么？
• 31、说说Zookeeper中的脑裂？
• 32、Zookeeper脑裂是什么原因导致的？
• 33、Zookeeper 是如何解决脑裂问题的？
• 34、说说 Zookeeper 的 CAP 问题上做的取舍？
• 35、watch 监听为什么是一次性的？

Dubbo 1、说说一次Dubbo服务请求流程？

上图中角色说明：

2、Dubbo工作原理

工作原理分 10 层：
第一层：service 层，接口层，给服务提供者和消费者来实现的（留给开发人员来实现）；
第二层：config 层，配置层，主要是对 Dubbo 进行各种配置的，Dubbo 相关配置；
第三层：proxy 层，服务代理层，透明生成客户端的 stub 和服务单的 skeleton，调用的是接口，实现类没有，所以得生成代理，代理之间再进行网络通讯、负责均衡等；
第四层：registry 层，服务注册层，负责服务的注册与发现；
第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务；
第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控；
第七层：protocol 层，远程调用层，封装 rpc 调用；
第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步；
第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口；
第十层：serialize 层，数据序列化层。

3、Dubbo支持哪些协议？

还有三种，混个眼熟就行：Memcached 协议、Redis 协议、Rest 协议。

4、注册中心挂了，consumer还能不能调用provider？

可以。因为刚开始初始化的时候，consumer 会将需要的所有提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。但是 provider 挂了，那就没法调用了。

关键字：consumer 本地缓存服务列表。

5、怎么实现动态感知服务下线的呢？

服务订阅通常有 pull 和 push 两种方式：
pull 模式需要客户端定时向注册中心拉取配置；
push 模式采用注册中心主动推送数据给客户端。

Dubbo ZooKeeper 注册中心采用是事件通知与客户端拉取方式。服务第一次订阅的时候将会拉取对应目录下全量数据，然后在订阅的节点注册一个 watcher。一旦目录节点下发生任何数据变化，ZooKeeper 将会通过 watcher 通知客户端。客户端接到通知，将会重新拉取该目录下全量数据，并重新注册 watcher。利用这个模式，Dubbo 服务就可以做到服务的动态发现。

注意：ZooKeeper 提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除。

6、Dubbo负载均衡策略？

随机（默认）：随机来
轮训：一个一个来
活跃度：机器活跃度来负载
一致性 hash：落到同一台机器上。

7、Dubbo容错策略

failover cluster 模式
provider 宕机重试以后，请求会分到其他的 provider 上，默认两次，可以手动设置重试次数，建议把写 *** 作重试次数设置成 0。
failback 模式
失败自动恢复会在调用失败后，返回一个空结果给服务消费者。并通过定时任务对失败的调用进行重试，适合执行消息通知等 *** 作。
failfast cluster 模式
快速失败只会进行一次调用，失败后立即抛出异常。适用于幂等 *** 作、写 *** 作，类似于 failovercluster模式中重试次数设置为 0 的情况。
failsafe cluster 模式
失败安全是指，当调用过程中出现异常时，仅会打印异常，而不会抛出异常。适用于写入审计日志等 *** 作。
forking cluster 模式
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读 *** 作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
broadcacst cluster 模式
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

8、Dubbo动态代理策略有哪些？

默认使用 javassist 动态字节码生成，创建代理类，但是可以通过 SPI 扩展机制配置自己的动态代理策略。

9、说说 Dubbo 与 Spring Cloud 的区别？

这是很多面试官喜欢问的问题，本人认为其实他们没什么关联之处，但是硬是要问区别，那就说说吧。
回答的时候主要围绕着四个关键点来说：通信方式、注册中心、监控、断路器，其余像 Spring 分布式配置、服务网关肯定得知道。

通信方式
Dubbo 使用的是 RPC 通信；Spring Cloud 使用的是 HTTP RestFul 方式。
注册中心
Dubbo 使用 ZooKeeper（官方推荐），还有 Redis、Multicast、Simple 注册中心，但不推荐。；
Spring Cloud 使用的是 Spring Cloud Netflix Eureka。
监控
Dubbo 使用的是 Dubbo-monitor；Spring Cloud 使用的是 Spring Boot admin。
断路器
Dubbo 在断路器这方面还不完善，Spring Cloud 使用的是 Spring Cloud Netflix Hystrix。
分布式配置、网关服务、服务跟踪、消息总线、批量任务等。
Dubbo 目前可以说还是空白，而 Spring Cloud 都有相应的组件来支撑。

10、Zookeeper和Dubbo的关系

Zookeeper的作用
zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

dubbo
是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。 注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

zookeeper和dubbo的关系
Dubbo 的将注册中心进行抽象，它可以外接不同的存储媒介给注册中心提供服务，有
ZooKeeper，Memcached，Redis 等。

引入了 ZooKeeper 作为存储媒介，也就把 ZooKeeper 的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个 ZooKeeper 群配合相应的 Web 应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper 集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入自己的 URL 地址，这个 *** 作就完成了服务的发布。 其他特性还有 Mast 选举，分布式锁等。

MQ 1、为什么使用MQ

核心：解耦,异步,削峰
1）解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。
（2）异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 +450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。 （3）削峰：减少高峰时期对服务器压力。

2、MQ有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。
缺点有以下几个：

系统可用性降低 系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩溃，你不就完了？

系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？问题一大堆。

一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了

3、Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别？

对于吞吐量来说kafka和RocketMQ支撑高吞吐，ActiveMQ和RabbitMQ比他们低一个数量级。对于延迟量来说RabbitMQ是最低的。

1.从社区活跃度
按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。
2.持久化消息比较
ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。
3.综合技术实现
可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。
RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
4.高并发
毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。
5.比较关注的比较， RabbitMQ 和 Kafka
RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。
另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

4、如何保证高可用的？

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ为例子讲解第一种 MQ 的高可用性怎么实现。RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式

普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写 *** 作。

5、如何保证消息的可靠传输？如果消息丢了怎么办

6、如何保证消息的顺序性

先看看顺序会错乱的场景：RabbitMQ：一个 queue，多个 consumer，这不明显乱了；

7、 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

8、让你来设计一个消息队列，你会怎么设计

zookeeper 1、说说zookeeper是什么？

直译：从名字上直译就是动物管理员，动物指的是 Hadoop 一类的分布式软件，管理员三个字体现了 ZooKeeper 的特点：维护、协调、管理、监控。
**简述：**有些软件你想做成集群或者分布式，你可以用 ZooKeeper 帮你来辅助实现。
特点：
最终一致性：客户端看到的数据最终是一致的。
可靠性：服务器保存了消息，那么它就一直都存在。
实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。
独立性（等待无关）：不同客户端直接互不影响。
原子性：更新要不成功要不失败，没有第三个状态。

注意：回答面试题，切忌只是简单一句话回答，可以将你对概念的理解，特点等多个方面描述一下，哪怕你自己认为不完全切中题意的也可以说说，面试官不喜欢会打断你的，你的目的是让面试官认为你是好沟通的。当然了，如果不会可别装作会，说太多不专业的想法。

2、Zookeeper有哪些应用场景？

数据发布与订阅
发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZooKeeper节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。

数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点:

1. 数据量小的KV
2. 数据内容在运行时会发生动态变化
3. 集群机器共享，配置一致
   
   ZooKeeper 采用的是推拉结合的方式。
   1 推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知
   2 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据
   
   
   
   1、分布式环境下，配置文件管理和同步是一个常见问题。
   一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
   对配置文件修改后，希望能够快速同步到各个节点上。
   2、配置管理可交由ZooKeeper实现。
   可将配置信息写入ZooKeeper上的一个Znode。
   各个节点监听这个Znode。
   一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

集群管理
所谓集群管理就是：是否有机器退出和加入、选举master。
集群管理主要指集群监控和集群控制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行 *** 作与控制。开发和运维中，面对集群，经常有如下需求:

1. 希望知道集群中究竟有多少机器在工作
2. 对集群中的每台机器的运行时状态进行数据收集
3. 对集群中机器进行上下线的 *** 作
   集群管理结构图如下所示：
   
   1、分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。
   2、可交由ZooKeeper实现。
   可将节点信息写入ZooKeeper上的一个Znode。
   监听这个Znode可获取它的实时状态变化。
   3、典型应用
   Hbase中Master状态监控与选举。
   利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有
   多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功
   
   
   

3、说说Zookeeper的工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们 分别是恢复模式（选主）和广播模式（同步）。
Zab协议 的全称是 Zookeeper Atomic Broadcast** （Zookeeper原子广播）。Zookeeper 是通过Zab 协议来保证分布式事务的最终一致性。Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加 上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一 个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

epoch：可以理解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。

每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻。
LEADING：当前Server即为选举出来的leader。
FOLLOWING：leader已经选举出来，当前Server与之同步

4、请描述一下Zookeeper的通知机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

5、Zookeeper对节点的watch监听通知是永久的吗？

不是，一次性的。无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。

6、Zookeeper 集群中有哪些角色？

在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。为什么保证奇数？主要是为了选举算法。

7、Zookeeper集群中Server有哪些工作状态？

LOOKING
寻找 Leader 状态；当服务器处于该状态时，它会认为当前集群中没有 Leader ，因此需要进入Leader 选举状态
FOLLOWING
跟随者状态；表明当前服务器角色是 Follower
LEADING
领导者状态；表明当前服务器角色是 Leader
OBSERVING
观察者状态；表明当前服务器角色是 Observer

8、 Zookeeper 集群中是怎样选举leader的？

当Leader崩溃了，或者失去了大多数的Follower，这时候 Zookeeper 就进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个状态LOOKING 。
Zookeeper 有两种选举算法：基于 basic paxos 实现和基于 fast paxos 实现。默认为 fast paxos

9、Zookeeper 是如何保证事务的顺序一致性的呢？

10、ZooKeeper 集群中个服务器之间是怎样通信的？

11、ZooKeeper 分布式锁怎么实现的？

如果有客户端1、客户端2等N个客户端争抢一个 Zookeeper 分布式锁。大致如下：

1. 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点
2. 如果自己不是第一个节点，就对自己上一个节点加监听器
3. 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。

12、了解Zookeeper的系统架构吗？

13、Zookeeper为什么要这么设计？

14、你知道Zookeeper中有哪些角色？

15、你熟悉Zookeeper节点ZNode和相关属性吗？

16、请简述Zookeeper的选主流程

17、为什么Zookeeper集群的数目，一般为奇数个？

18、知道Zookeeper监听器的原理吗？

1. 创建一个Main()线程。
2. 在Main()线程中创建两个线程，一个负责网络连接通信（connect），一个负责监听
   （listener）。
3. 通过connect线程将注册的监听事件发送给Zookeeper。
4. 将注册的监听事件添加到Zookeeper的注册监听器列表中。
5. Zookeeper监听到有数据或路径发生变化时，把这条消息发送给Listener线程。
6. Listener线程内部调用process()方法

19、说说Zookeeper中的ACL 权限控制机制

20、Zookeeper 有哪几种几种部署模式？

Zookeeper 有三种部署模式：

1. 单机部署：一台集群上运行；
2. 集群部署：多台集群运行；
3. 伪集群部署：一台集群启动多个 Zookeeper 实例运行。

21、Zookeeper集群支持动态添加机器吗？

其实就是水平扩容了，Zookeeper 在这方面不太好。两种方式：
全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。

22、描述一下 ZAB 协议

23、ZAB 和 Paxos 算法的联系与区别？

24、ZooKeeper 宕机如何处理？

ZooKeeper 本身也是集群，推荐配置奇数个服务器。因为宕机就需要选举，选举需要半数 +1 票才能通过，为了避免打成平手。进来不用偶数个服务器。

25、 描述一下 ZooKeeper 的 session 管理的思想？

26、ZooKeeper 负载均衡和 Nginx 负载均衡有什么区别？

27、说说ZooKeeper 的序列化

28，在Zookeeper中Zxid 是什么，有什么作用？

29、讲解一下 ZooKeeper 的持久化机制

30、Zookeeper选举中投票信息的五元组是什么？

31、说说Zookeeper中的脑裂？

32、Zookeeper脑裂是什么原因导致的？

33、Zookeeper 是如何解决脑裂问题的？

34、说说 Zookeeper 的 CAP 问题上做的取舍？

35、watch 监听为什么是一次性的？