上一篇文章简单介绍了一下zk能够作为分布式服务的注册中心的相关内容，可参见文章 Zookeeper作为分布式服务的注册中心 但是据我所知阿里的HSF使用的并不是zk来作为注册中心的，本篇文章简单分析下zk的CAP模型以及他作为注册中心的缺点。CAP理论参见分布式系统中的CAP理论
CAP理论：C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。
zookeeper是一种提供强一致性的服务，在分区容错性和数据一致性上做了一定的折中。ZooKeeper是个CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。
实际上zookeeper提供的只是单调一致性。主要原因：
1. 假设有2n+1个server，在同步流程中，leader向follower同步数据，当同步完成的follower数量大于 n+1时同步流程结束，系统可接受client的连接请求。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。
2. follower接收写请求后，转发给leader处理；leader完成两阶段提交的机制。向所有server发起提案，当提案获得超过半数（n+1）的server认同后，将对整个集群进行同步，超过半数（n+1）的server同步完成后，该写请求完成。如果client连接的并非同步完成follower，那么得到的并非最新数据，但可以保证单调性。
ZooKeeper是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了。作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务因为他的CP模型变得可能不是那么合适了。
1、在zk集群中如果leader宕机，会进入leader选举过程，在这个过程中zk不对外提供服务的，这回造成注册服务短时不可用，如果网络不稳定或者延迟比较高这个过程可能会比预期的要久。
2、服务的淘汰，在zk中通过心跳服务监控服务的可用，如果心跳延迟zk会认为服务不可用将服务淘汰，这个功能本身没有问题。但是在发生网络分割时这就非常危险了，因为哪些心跳延迟的服务是由于网络的问题而被剔除出去的，服务本身还是健康的。
所以zk作为服务注册中心不是不可以（目前很多公司都在用，很多公司服务都在同一机房部署网络问题很少出现），但是我们要了解它的问题所在在实际中避免或者能够及时解决可能出现的问题。
网友评论