zookeeper是常见的分布式工具，其基本用途：
- 服务注册管理
- 选举master
- 分布式锁
基本概念：
- session：client和zooKeeper之间的会话连接。client会周期性地向zooKeeper发送心跳，如果zookeeper在特定时间内不能收到心跳（可能是client死掉或者网络不通），该session会结束。
- znode：树形结构的节点，分为三种：永久znode，临时znode（session结束会删除），顺序znode（分布式锁）。
- 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了）：
这样循环往复下去...... 分布式锁就可以实现了！
