张大胖所在的公司这几年发展得相当不错，业务激增，人员也迅速扩展。
张大胖也锐意进取，坐上了架构师的“宝座”。
随着技术的发展，公司的IT系统早已从单机转向了分布式， 分布式带来了巨大的挑战。
周一上班，找张大胖的人就络绎不绝。
张大胖一看这个图就明白怎么回事了，为了支持高并发，OrderService被部署了4份，每个客户端都保存了一份服务提供者的列表，但是这个列表是静态的（在配置文件中写死的）！
如果url_3所在的机器down了，或者新增了一个url_5，客户端根本不知道，可能还在傻乎乎地尝试那些已经坏掉的实例呢！
张大胖想到，应该有个注册中心，首先给这些服务命名（例如orderService），其次那些OrderService 都可以在这里注册一下。
不知道是不是下意识的行为，张大胖把这个注册中心的数据结构设计成为了一个树形结构。
当然需要在注册中心和各个服务实例直接建立Session, 让各个服务实例定期地发送心跳，如果过了特定时间收不到心跳，就认为这个服务实例挂掉了，Session 过期， 把它从树形结构中删除，客户端就查不到了。
小梁前脚离开， 小王就风风火火地来了。
为了高可用，一个Batch Job在三台机器上部署了三份，但是同一个时刻只能有一个运行！
如果其中某个不幸down掉，剩下的两个就需要做个选举，选出来的那个Batch Job 需要“继承遗志”，继续工作。
小王很聪明， 他立刻就明白了怎么回事。
当前Master的机器挂掉的时候，需要把/master给删掉。
很明显，注册中心也需要和各个机器通信，看看他们是否活着。
这里还有一个复杂的情况， 如果机器1并没有死掉，只是和注册中心长时间连接不上。
实际上机器1如果无法联系注册中心了，需要停止Batch Job才行，否则就可能和别人冲突。
等到和注册中心再次连接上以后，才知道自己已经不是master了，老老实实地等下一次机会吧。
小王刚走， 小蔡马上就闪了进来。
张大胖一想果然是这样，看来是小瞧这个问题了，分布式锁不是Master选举， 得考虑公平问题。
系统1持有了锁，就可以对共享资源进行操作了， 操作完成以后process_01这个节点删除， 再创建一个新的节点（编号变成process_04了）
这样循环往复下去...... 分布式锁不就实现了？
张大胖决定去向CTO Bill 汇报，组织人力进行开发。
没想到Bill一针见血，一下子就指出了重大缺陷。
这个注册中心也得有多台机器来保证高可用啊！
小王、小梁、小蔡的原始问题没有解决，单单是这个注册中心就要了命了。以自己公司的技术实力，搞出一套这样的注册中心简直是不可能完成的任务！
Zookeeper 有这些核心的概念：
1. Session ：表示某个客户系统（例如Batch Job）和ZooKeeper之间的连接会话, Batch Job连上ZooKeeper以后会周期性地发送心跳信息， 如果Zookeeper在特定时间内收不到心跳，就会认为这个Batch Job已经死掉了, Session 就会结束。
2. znode : 树形结构中的每个节点叫做znode， 按类型可以分为永久的znode（除非主动删除，否则一直存在），临时的znode（Session结束就会删除）和 顺序znode（就是小蔡的分布式锁中的process_01,process_02.....）。
3. Watch ：某个客户系统（例如Batch Job）可以监控znode， znode节点的变化（删除，修改数据等）都可以通知Batch Job， 这样Batch Job可以采取相应的动作，例如争抢着去创建节点。
更多精彩漫画，尽在码农翻身！
转载：https://blog.csdn.net/coderising/article/details/114826693