一、zk的选举模式：
master节点选举，主节点挂了以后，从节点就会开始接手工作，并且保证这个节点是唯一的，这也是所谓的首脑模式，从而保证我们的集群是高可用的。
eg：比如说一个公司的所有高管去外国出差，那他们呢分别坐了不同的飞机，为啥呢，就是怕万一有的飞机失事，其他别的飞机的领导可以接手他的事，保证公司的正常运行。这就是所谓的集群高可用（ 略略略 ~ ）
二、统一配置文件管理
即只需要部署一台服务器，则他可以同时把相同的配置文件同步更新到其他所有服务器，此操作在云计算中用的很多。
but someone will say，why not let 运维多备份几个配置，再上传到别的服务器呢？那其实是不对的啦。
假设场景：
这里有三个集群，假设修改了redis统一配置时，需要在这九台机子上同时镜像（实际中更是可能有成千上万个集群），此时，运维工程师如果一个个备份再上传则工作量太大。
那么，zk的统一配置文件管理此时只需要修改一台电脑，那这台电脑再分发到其他的电脑，做一个统一的部署，简化步骤，提高效率。
三、发布与订阅模式
类似于消息队列MQ（ amq，rmq...）,dubbo发布者把数据存在znode上，订阅者会读取这个数据。
比如说在/immoc/znode这个节点上，存储了一些数据，发布者在这个节点上发布数据（增加或别的数据修改操作），订阅者在读取这个节点数据的后，对数据做一些自己的修改。
四、提供分布式锁
分布式环境中不同进程之间争夺资源，类似于多线程中的锁
五、集群管理
集群中保证数据的强一致性。
假设这个集群中有三个节点，客户端一开始向主节点（最左边那个）中写入数据XYZ，此时，数据会被同时同步部署到其他从节点；然后呢，这个客户端断开了与主节点的连接，去连接其他的一个从节点了，依然可以读到与主节点相同的数据，这就是数据的强一致性，嘻嘻~
