Zookeeper的虚伪集群：
1、概念：在一台机器上面根据端口号的不同去做区分不同的节点从而实现集群。
步骤：
①、在zookeeper的conf目录下面复制三个相同的配置文件：
zoo.cfg(默认加载的),zoo1.cfg,zoo2.cfg(这两个文件不是默认加载的，需要自己去指定)。启动Zookeeper的时候需要指定配置文件的位置。
②、需要创建三个不同数据存储目标然后配置三个myid/Serverid：每一个的myId代表一个服务器的标识，标识必须是唯一的，不能重复。
然后在data里面设置一个服务的id：将1写入到myid里面去。
③、编写集群中zoof的配置文件内容:
格式：server.x=ip:A:B
x:服务的唯一的编号(myid的值/serverid)
A:与leader通信端口
B:初始化或者leader出现问题时候的投票通信端口
③、启动集群中的服务节点,并测试查看节点的状态：
currentEpoch:代表选举多少轮把leader给选举出来。
选举了一轮就把leader给选举了出来。
acceptedEpoch:代表投票数
投票数也是1。
zookeeper_server.pid：代表进程编号
Leader选举出来，它会去指挥下面所有的跟随者去做事情：
zk的集群一般是基数的，因为有 投票 选举机制的：
如果三台集群的话，一台leader,两台是follow，其中一台follow挂 掉的话，整个集群也就挂掉了，因为 偶数的话无法投票选出Leader。
在zookeeper3.4版本的时候选举有一些变化：原有三种选举的方式换成只有一种。他会根据当前的操作事务id比较，如果事务的id大的话，会当选为leader。如果事务id相同的话就会判断serverId，如果serverId越大的话也会当选为leader，所以这时有不同的选举机，这样的话就保证了高可用。
事务ID就是czxid，事务Id是每操作一次事务，都会增加1，默认的值是0。
连下客户端：
如果想要连接2182的话：
如果想要连接2183的话：
这就是集群的连接。
这个集群是高可用的集群，由中心化的思想。做任何的读和写的操作都将落在leader上去操作。而follow得操作只负责拷贝，广播到下面得follow得节点上上面去同步leader上面的数据
例如：leader的节点下创建一个路径：
然后用2182端口的zookeeper去登录客户端的话：也会查到leader的节点。
数据就同步过来了。
redis是主从的，是日志文件的拷贝。而zookeeper是原子广播(不会出现操作事务的，因为它的事务是强一致性的)。
如果返回给leader的结果ACK超过了半数也就是所有的(follow节点/2)+1>半数，就认为是成功的操作，就认为是事务正常提交了，如果ACK的次数没有超过半数，就认为是失败的(rollback:回滚)。
所以zk是一个Automic bordcast:原子的广播。
半数的原因：因为zk是一个高可用的组件，为了达到高可用的状态。
而且在通信的过程中，发现某一个follow节点断开的话,leader发送过去，没有得到follow的消息，心跳没有返回了，就会把这个节点给丢弃掉，这就是中心化的思想。
如果把leader给挂掉的话：
然后2变成了leader，1还是follow。
所以集群zk就是一个高可用的状态，一样的可以对外提供数据。
现在把第三台给启动：这时第三台就为follow节点了。
