zookeeper比较重要的一个模式：选举模式，这也是高可用的一个体现。公司的董事长、副董事长、董事会常理员以及老总和副总，他们并不会乘坐同一班飞机，而是会分为两班或者三班飞机一起去，也就是我们所谓的集群高可用。
让运维去多做几份备份，把不同的备份或者说是同样的备份上传到相同的服务器或者说是不同的服务器那么就可以了，其实这样子是不对的。我们做一个假设，我们假设现在修改了redis的配置，那么修改redis的配置的话我们是需要在我们的一些生产环境上去做相应的修改。订单服务部署在A、B、C三台服务器，那么它是一个订单服务集群。那么相同的有用户服务集群，还有是账单服务集群。那么目前总共是有9台机子，我们修改了redis一个配置之后，它其实是需要在这9台机子上同时生效，那么这现在仅仅只是3种服务，在微服务中其实是会有很多很多的服务，甚至是有成千上百个，对于我们的运维工程师来说这其实是一个不小的工作量，所以说通过zookeeper它可以只修改一台电脑，然后通过这一台电脑再分发到其他的电脑，它可以做一个统一的部署，那么这样子会简化他的工作，提高了效率。
Dubbo它也是基于消息队列MQ的。
那么这也就是所谓的发布者与订阅者模式。
集群和分布式环境中，不同服务器对资源的一个争抢。对于同一个文件来讲，对于这么多的并发，那么文件它到底应该听谁的呢？是不是有先来后到，还是说最后一个来的先去修改呢？其实不一样的。我们需要对它加一个锁机制，也就是说当我们A服务器在进行读操作的时候，我们下一回啊只能进行一个个排队，也就是说我们A去操作的时候，下面的人就是进行了一个阻塞，也就是说相当于是一个读书吧。当A在读一本书的时候，那么他是拿在手里的，总共就只有一本书，那么下面的其他的一些用户需要去看书或者说对书里面做一些笔记或者说是修改的话那么肯定是要等到A把这本书归还到读书管理员之后他们才能去看，也就是说下面的人会一个一个排队，也就是说他们会被阻塞住，直到A释放，A释放完毕之后再B释放，然后依次类推，他们是一个顺序。
如果说客户端现在和主节点切断了链接，切断链接之后它不想去读了，那么直接去读附属节点，那么附属节点的时候它们的数据也是有的。也就是说我们客户端在不管链接任何一台机子的时候，它都可以读到数据的一致性。这个就是数据一致性的表现。
