zooKeeper基础

zookeeper是常见的分布式工具，其基本用途：

1. 服务注册管理
2. 选举master
3. 分布式锁

基本概念：

1. session：client和zooKeeper之间的会话连接。client会周期性地向zooKeeper发送心跳，如果zookeeper在特定时间内不能收到心跳（可能是client死掉或者网络不通），该session会结束。
2. znode：树形结构的节点，分为三种：永久znode，临时znode（session结束会删除），顺序znode（分布式锁）。
3. watch：client会监控zookeeper，znode节点的变化（删除，修改数据等）都可以通知client。

服务治理

耦合严重的RPC，需要增加一个中间件去掉耦合。

注册中心的数据结构是树形的：

如果某个服务实例不幸down掉了，那它在树结构中对于的节点也必须删除， 这样客户端就查询不到了。

Master选举

三个Batch Job启动以后，都去注册中心争抢着去创建一个树的节点（例如/master ），谁创建成功谁就是Master （当然注册中心必须保证只能创建成功一次，其他请求就失败了），其他两个Batch Job就对这个节点虎视眈眈地监控，如果这个节点被删除，就开始新一轮争抢，去创建那个/master节点。

这里还有一个复杂的情况， 如果机器1并没有死掉，只是和注册中心长时间连接不上，注册中心会发现Session超时，会把机器1创建的/master删除。 让机器2和机器3去抢，如果机器3成为了master, 开始运行Batch Job, 但是机器1并不知道自己被解除了Master的职务， 还在努力的运行Batch Job，这就冲突了！

看来机器1必须得能感知到和注册中心的连接断开了，需要停止Batch Job才行，等到和注册中心再次连接上以后，才知道自己已经不是master了，老老实实地等下一次机会吧。

分布式锁

然后各个系统去检查自己的编号，谁的编号小就认为谁持有了锁， 例如系统1。

系统1持有了锁，就可以对共享资源进行操作了， 操作完成以后process_01这个节点删除， 再创建一个新的节点（编号变成process_04了）：

这样循环往复下去...... 分布式锁就可以实现了！

参考：什么是Zookeeper?