复杂问题简单化
zookeeper就是一个精简的文件管理器，他的每个节点就如同文件或文件夹。
高可用性：ZooKeeper可以运行在一组服务器上，同时它们被设计成高可用性，为你的应用程序避免单点故障。
zookeeper简单的来说就是个znode节点。
每个Znode由3部分组成:
① stat：此为状态信息, 描述该Znode的版本, 权限等信息
② data：与该Znode关联的数据
③ children：该Znode下的子节点
Znode又分为了两种类型：临时节点和永久节点。
① 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。
② 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
再说一下zookeeper的一些特性。
zookeeper是分布式部署的，也就是在多天机器部署，意味着就是说某太机器down掉了，并没有什么影响。特性二当客户端与zookeeper服务建立连接后就可以创建临时节点，但是与服务断开连接后，节点会被自动删除。
通过这些特性实现一个简单的master服务
也就是说防止服务器down机，采用多台服务器发布服务。但是同一时间只有一台服务器提供服务，当主服务挂掉了，备用服务器会立即接班。
这边简单定义一下
服务器A、服务器B
客户端A
刚开始服务器A、服务器B同时连接到zookeeper服务器。
分别注解一个临时节点。
假如说服务器A先注册znode1，服务器B后注册znode2。
这是通过zookeeper排序机制，获取第一个节点znode1设置为master节点（永久节点，里面包含服务器的配置信息）。客户端通过获取master节点，通过里面的信息连接到master服务器，请求服务。
假如说这是服务器Adown了。以为这他会与zookeeper断开连接，znode1节点会自动删除。同时出发watch事件，这时会重新选举master，也就是znode2。当服务器A恢复正常了，会连接到zookeeper服务器，同时再次注册节点znode3。等待参与选举。假如说此时服务器由于网络原因，突然与zookeeper断开连接了，然而实际上并没有down机。此时zonde2也会被删除，然后重新选举master节点。这样会照成没必要master切换。如何解决这个问题呢？也就是说当master挂掉的时候，选举master节点时。上次的master节点有优先选择权。怎么实现呢？在选举节点时，判断当前节点是否为上次的master节点，如果是，立即选举。否则等等5秒后再参与选举。这样就不会造成网络中断切换服务区照成的不必要的开销了。
