本文是什么是Zookeeper?的笔记，从使用者的角度描述了Zookeeper有什么用处，至于它内部是如何工作

解决在线服务列表同步问题

现在公司的IT系统早已经从单机转向了分布式，然而分布式系统带来了很多的问题。比如说

现在公司开发了一个RPC框架来给各组开发人员使用，为了支持高并发，OrderService部署了4份，也就意味着每个客户端保存了一份服务提供者的列表，但是这个列表是在配置文件中写死了的，意味着如果某台服务器down了，客户端并不知道，依然会尝试访问。

这样客户端和服务提供者是紧耦合，要解决这个问题，可以增加一个中间层。

image.png

RPC指的是远程过程调用，就是部署在服务器A的应用要调用服务器B上的函数，由于不在一个内存空间，所以需要使用网络来表达怎么调用以及要调用的内容。RPC就是要像调用本地的函数一样去调远程函数。

那么如何设计这个中间层呢？

可以使用一个注册中心，它保存了能提供的服务的名称，以及URL。首先这些服务会在注册中心进行注册，当客户端来查询的时候，只需要给出名称，注册中心就会给出一个URL。

这个注册中心类似于一个上帝的角色，它可以了解全局有那些服务提供者，以及这些提供者的状态。

所有的客户端在访问服务前，都需要向这个注册中心进行询问，以获得最新的地址。

image.png

注册中心可以是树形结构，每个服务下面有若干节点，每个节点表示服务的实例。

注册中心和各个服务实例直接建立Session，要求实例们定期发送心跳，一旦特定时间收不到心跳，则认为实例挂了，删除该实例。

image.png
image.png

Job协调问题

三个Job的功能相同，部署在三个不同的机器上，要求同一时刻只有一个可以运行，也就是如果有一个宕了的话，需要在剩下的两个中选举出Master继续工作。

image.png
所以这三个Job需要互相协调。

• 使用共享数据库表。我们知道数据库主键不能冲突，可以让三个Job向表中插入同样的数据，谁成功谁就是Master。缺点是如果抢到Master的Job挂了，则记录永远存在，其他的Job无法插入数据。所以必须加上定期更新的机制。

• 让Job在启动之后，去注册中心注册，也就是创建一个树节点，谁成功谁是Master。这样，如果节点删除了，就开始就开始新一轮争抢。

image.png

同样实时知道是否当前的Master还需要存活，所以注册中心需要与各个机器通信。

不过这里存在一个问题，如果机器没有死掉，只是与注册中心的通信断了，所以长时间连接不上。然后注册中心把树节点/master删除，另外两台机器重新抢到了Master，但是原来的Master并不知道啊，所以还在努力的运行Job，这就冲突了。

解决方法当然是机器也需要感知到自己与注册中心连接断了，然后停止Job。等到再次与注册中心连接上，才知道自己已经不是Master了。

image.png

分布式锁

多个机器上的系统同时对某个资源进行争抢，如果在同一个进程中加个锁就可以了。但是现在是分布式的，只能使用分布式锁

image.png

• 使用Master选举的方式，让大家去抢，谁能抢到就创建一个/distribute_lock节点，读完以后就删除，让大家再来抢。缺点是某个系统可能多次抢到，不够公平。

• 让每个系统在注册中心的/distribute_lock下创建子节点，然后编号。

  • 每个系统检查自己的编号，谁小认为谁持有了锁，比如下图中是系统1持有了锁。

    
    image.png

  • 系统1操作完成以后，就可以把process_01删除了，再创建一个新的节点 process_04。此时是process_02最小了，所以认为系统2持有了锁。

    
    image.png
  • 如此循环下去，分布式锁就实现了。

image.png

注册中心的高可用性

如果注册中心只有一台机器，一旦挂了，整个系统就宕了。所以需要多台机器来保证高可用性。这样引出了新的问题，比如树形结构需要在多台机器之间进行同步，通信超时了怎么办，如何保证树形结构在机器之间的强一致性。

ZooKeeper

Zookeeper就是这样类似的解决方案。它已经实现了树形结构在多台机器之间的可靠复制。

关键概念如下：

• Session：表示Job与ZooKeeper之间的会话，Zookeeper会定期发送心跳，如果特定时间收不到心跳则结束会话。

• znode：树形结构中的每个节点就叫znode，可以分为

  • 永久znode：除非主动删除，否则一直存在

  • 临时znode：Session一旦结束就删除

  • 顺序znode：也就是分布式锁中的process_01，process_02

• Watch：客户系统Job可以监控znode的变化，同时znode变化了以后也会通知Job。这样Job可以继续争抢创建节点。

image.png