本文是什么是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
