zookeeper理论篇

zookeeper 是什么

zookeeper是一个分布式服务管理框架，基于观察者设计模式，他负责管理和存储大家都关心的信息，并且接受观察者的观察监控，一旦数据节点发生变化，zookeeper就负责通知注册的观察者。总体来说就是zookeeper就是分布式文件系统数据库+通知机制。具有的特性包括：

• 分布式中只有一个leader，但有多个follower
• 集群中只要有半数以上的节点存活，zookeeper就可以提供服务
• 数据全局一致：ZAB协议保证每一个server都保存一样的数据，client无论链接哪一个server 都读取的副本一样
• 有序执行：来自同一个client的更新或操作
• 事务原子性：一次成功或失败。
• 实时性：一定的时间内，可以看到最新的数据。

zookeeper 数据结构

数据结构就是一个文件系统的路径，也类似一个树模型，最上层是一个root节点，然后在root节点下新建节点ZNode，并且大小是1M，并且同级下不允许有相同的ZNode节点，因为zookeeper要通过root到ZNode的路径做唯一标识。

选举机制：半数以上机制

在安装分布式zookeeper的时候，每台机器都有一个myid作为标识符，当服务器一台一台都启动的时候，会选择myid最大的投票作为leader，
目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

（1）服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。

（2）服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。

（3）服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。

（4）服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。

（5）服务器5启动，后面的逻辑同服务器4成为小弟。

由于网络问题，其实广播投票结果时会带上类似时间戳的zxid属性，防止过期的广播投票影响选举。

于是一般集群规模都是奇数，因为5台、6台挂掉3台机器都会使服务不可用，所以没必要多部署一台机器，一般都奇数就可以。考虑到一个leader和多个follower ，那么集群至少3台机器。

监听原理

单独一个main方法来负责监听：

• 监听路径
• 监听节点数据

这个main线程会创建一个zkclient，它会负责监听，其中main线程还有一个process方法，来处理监听变化后的动作。

ZAB协议： Zookeeper Atomic Broadcast （Zookeeper原子广播）

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。参考了prxos算法，但主要为了zookeeper设计的，它主要为了解决两个问题：

• （1）leader服务器是如何把数据更新到所有的Follower的。

• （2）Leader服务器突然间失效了，怎么办？

因此ZAB协议为了解决上面两个问题，设计了两种模式：

• （1）消息广播模式：把数据更新到所有的Follower

• （2）崩溃恢复模式：Leader发生崩溃时，如何恢复

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

它主要负责消息广播和崩溃恢复：

• 消息广播
  过程类似2PC协议的话，leader将请求发给所有的follower，有一半follower收到后并返回ack命令，则leader 会commit该事务，并通知给所有follower。这里要注意集群中只有一个leader节点。
• 崩溃恢复
  一个follower成为leader之后，首先会去更改自己的zxid，然后对比之前最新的事务，跟其他follower进行对比，这样回退其他follower的事务，直到有一个事务已经有半数机器同意了，然后开启leader自己的事务同步。

问题探索

1、脑裂问题

脑裂是原本一个集群，由于网络问题导致集群变为了两个子集群，网络相互隔离，无法通信，从而变为两个集群，但zookeeper不存在这个问题，因为集群个数是奇数，且要求超过半数存活才可以提供服务，如果分成两个子集群，肯定有一个子集群的个数不超过半个，整个子集群无法提供服务。所以zookeeper没有脑裂问题。

应用场景

• 服务器上、下线
  节点上挂着IP节点，服务器失去服务了，节点就下线了。
• 统一命名
  域名节点下挂着IP地址
• 统一配置管理
  配置信息写入znode中，其他服务来监听这个节点，节点有变更，就作出相应的读取配置信息的操作。
• 服务发现
• 集群管理
  znode的互相监听，可以帮助知道集群信息

优点

• 可靠存储系统：设计最初的需求之一，也是ZK特性中实现最好的部分，作为可靠存储ZK基本没出现过问题，仅此一项就可保证其的流行。

• 通知回调机制：通过创建节点与设置Watcher可以很方便的建立回调通知。ZK的所有应用都基于这个特性，没有这个机制那么机器监控相关的应用都不能处理，也就不会诞生后来在服务注册发现相关的使用方法。实际上为分布式系统提供节点间回调通知方法的系统真的很少，甚至可能只有ZK（大家可以提供一些其他答案？）

• 连接状态维护：ZK自动维护了客户端所在的应用与服务器通信连接状态的变化，可以比较简单地维护系统中的成员通信情况。主要是不需要自己再去处理麻烦的通信状态监控问题，比如断线后自动释放节点并产生回调。

• 文件系统模型：提供文件接口模型而不是锁接口，更具通用性。文件系统模型中文件与目录的概念可以映射多种含有层级关系的其他模型

• 自增长序列：这点包含了锁的本质，但是因为zk的模型设计导致判断与仲裁需在客户端进行

• 同步：数据在各个server之间同步

• 有序操作：zk本身的操作都是有序的操作。

缺点

• 不是高可用
  zookeeper是数据一致性的有利代表项目，cap理论中的满足CP条件的，网络隔离导致的某个时刻zookeeper将处于不可用，数据不一致问题常有发生，从当前微服务的架构思想上，必须保证高可用，zk的这种问题会导致服务不可用就太夸张了。

• 选举机制太慢
  一旦出现网络隔离，zookeeper就要发起选举流程。zookeeper的选举流程通常耗时30到120秒，期间zookeeper由于没有master，都是不可用的。对于网络里面偶尔出现的，比如半秒一秒的网络隔离，zookeeper会由于选举过程，而把不可用时间放大几十倍。

• qps有限
  大概一万多，很多需要自主缓存地址，或者对其二次开发，规模增大需要同步到更多机器 tps 会下降 ，那么这就意味zk的集群不能很大，这就陷入了一个死循环，导致集群整体qps tps 都是有上限的大概5w到顶啦。而且写、读性能很差，读要等写完成。一旦扛不住压力就会改掉，又要需要选举，这就是死循环。

• Zookeeper不能保证跨session的强一致性
  最终一致性，同session 循序一致性，比如session-A写入数据，session-B未必能读到；或者说，我改了某个节点，这时候网络抖了，导致 session 超时；重建新 session 可能无法读到之前的数据；这样机会导致难以避免的数据不一致。

• 原生api 比较难用，客户端也比较难用

• 监控信息很少

实际一点的应用

1、kafka 中zk应用

• kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。
• 而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡，这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)。
• Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition的leader，建立socket连接并发送消息。也就是说每个Topic的partition是由Lead角色的Broker端使用zookeeper来注册broker信息，以及监测partition leader存活性，
• Consumer端使用zookeeper用来注册consumer信息,其中包括consumer与topic的关系，consumer消费的partition列表等，同时也用来发现broker列表，并获取消息的偏移量。

0.8版本kafka支partition级别的replication，所以Kafka负责选出一个Broker节点作为controller来在一个partiiton内副本间进行Leader选举，维护出一个ISR；新版本考虑到zookeeper性能问题，已经弱化作用了。

参考博客

ZooKeeper数据不一致的定位过程 (3.4.11)
zookeeper缺点
kafka-zk
Apache Kafka中Zookeeper的角色
Zookeeper的优点与局限性
Zookeeper——一致性协议:Zab协议
Zookeeper之leader选举、节点间数据同步

Zookeeper 崩溃选举之后的数据同步过程详解