Spring Cloud：Zookeeper和Eureka的区别在哪？原文请关注公众号 程序员私房菜

CAP理论:
分布式系统中的重要的概念

• C（Consistency）:数据一致性.在分布式系统中,数据会有副本,由于网络或者机械故障等因素,可能有些副本数据写入正确,有些却写入错误或者失败,这样就导致原来数据的不一致,为了满足数据一致性规则,就是保证所有数据同步.
• A（Availability）:可用性:我们需要获取什么数据的时候,都能正常获取想要的数据.(允许可接受范围内的网络延迟),也就是说保证任何时候请求数据都能够正常响应.
• P（Partition Tolerance）:分区容错性.分区容错性.当网络通信发生错误时,集群仍然可用,不会因为某个节点挂了或者存在问题,而影响整个系统的正常运作.
  对于分布式系统,出现网络分区是不可避免的,因此分区容错性是必须具备的,也就是说,cap三者,p是必须的,是个客观存在的现实,不可避免,不可绕过.

1.ZOOKEEPER的cp原则
对于zookeeper来说,他是cp的.也就是说,zookeeper是保证数据的一致性的,但是必须注意一点是,zookeeper他不是强一致的,什么意思呢?
打个比方: 现在客户端A提交一个写的操作,zookeep在过半数节点操作成功之后就可以返回,但是此时,客户端b的读操作请求是a写操作尚未同步到的节点,name读取的就不是a的最新提交的数据了.
那如何保证强一致性呢?我们可以在读取数据的时候先执行一下sync操作,即与leader节点先同步一下数据再去取,这样才能保证数据的强一致性.
但是zookeeper有个缺陷,刚刚提到的leader节点,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举.问题在于.选举leader时间太长,30-120s,且选举期间整个zookeeper集群都是不可用的 ,这就导致在选举期间注册服务瘫痪.

在云部署的情况下,因网络问题使得zookeeper集群失去master节点较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的.如双十一当天,那就是灾难性的.

2. Eureka 的 AP 原则
   大规模网络部署时,失败总是在所难免的.因此我们无法回避这个问题.当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接dowm掉不可用.
   Eureka 在被设计的时候就考虑了这一点,因此在设计时优先保证也可用性,这就是ap原则.Eureka 各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务.
   而Eureka 的客户端在向某个Eureka 注册时如果发现连接失败,则会自动连接其他节点,只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证C原则）
   正因为应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。
   Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。