SpringCloud（三）Eureka服务注册与发现《4》（CAP原则和Eureka，Zookeeper的区别）

目录：

1、几种常见注册中心区别

2、在分布式数据库中的CAP原理CAP+BASE

2.1、传统的ACID分别是什么？

2.2、什么是CAP？

2.3、CAP图谱分析

2.4、CAP的3进2

2.5、与BASE的关系

3、作为服务注册中心，Eureka 比Zookeeper好在哪？

3.1、Zookeeper 保证的是CP（一致性和分区容错性）

3.2、Eureka 保证的是AP（可用性和分区容错性）

---

1、几种常见注册中心区别

Feature	Consul	zookeeper	etcd	euerka
服务健康检查	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳	可配支持
多数据中心	支持	—	—	—
kv存储服务	支持	支持	支持	—
一致性	raft	paxos	raft	—
cap	ca	cp	cp	ap
使用接口(多语言能力)	支持http和dns	客户端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持 long polling/大部分增量
自身监控	metrics	—	metrics	metrics
安全	acl /https	acl	https支持（弱）	—
spring cloud集成	已支持	已支持	已支持	已支持

2、在分布式数据库中的CAP原理CAP+BASE

2.1、传统的ACID分别是什么？

关系型数据库遵循ACID规则：事务在英文中是transaction，和现实中的交易很类似，它有如下四个特性：    
        A(Atomicity)原子性        
        C(Consistency)一致性
        I(Isolation)隔离性
        D(Durabilly)持久性

详细见：https://blog.csdn.net/u012440687/article/details/52116108

2.2、什么是CAP？

CAP是分布式系统中进行平衡的理论，它是由 Eric Brewer发布在2000年。

• C(Consistency)强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
• A(Availability)可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• (Partition tolerance)分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

2.3、CAP图谱分析

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。
因此，根据CAP原理将NoSQL数据库如下三类：

• CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
•  CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
•  AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类，如redis,mongdb等。
   

2.4、CAP的3进2

CAP原则又称CAP定理，指的是在一个分布式系统中，不可能同时满足CAP，由于分区容错性P是必须保证的因此只能在A和C之前权衡。所以，分区容错性是我们必须需要实现的。

• CA：传统MySQL、Oracle等关系型数据库。（NoSQL系统通常注重性能和扩展性，而非事务机制）
• AP：大多数网站架构的选择
• CP：Redis、MongoDB等非关系型数据库。

2.5、与BASE的关系

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE是下面三个术语的缩写：

• 基本可用（Basically Available）
• 软状态（Soft state）
• 最终一致（Eventually consistent）

1. 目前最快的KV数据库,10W次/S, 满足了高可用性。

2. Redis的k-v上的v可以是普通的值（基本操作：get/set/del） v可以是数值（除了基本操作之外还可以支持数值的计算） v可以是数据结构比如基于链表存储的双向循环list（除了基本操作之外还可以支持数值的计算，可以实现list的二头pop,push）。如果v是list，可以使用redis实现一个消息队列。如果v是set,可以基于redis实现一个tag系统。与mongodb不同的地方是后者的v可以支持文档，比如按照json的结构存储。redis也可以对存入的Key-Value设置expire时间。

3. Redis的v的最大远远超过memcache。这也是实现消息队列的一个前提。

3、作为服务注册中心，Eureka 比Zookeeper好在哪？

3.1、Zookeeper 保证的是CP（一致性和分区容错性）

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down调不可用。也就是说服务注册功能对可用性要求高于一致性。但zookeeper会出现这样的一种情况，当master节点因为网络故障与其他节点失去联系时，剩下的节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得zookeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

3.2、Eureka 保证的是AP（可用性和分区容错性）

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种之外保护机制，如果再15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

• 1、Eureka不再从注册列表中移除，因为长时间没收到心跳而应该过期的服务。
• 2、Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
• 3、当网络稳定时，当前实例新的注册信息会被同步到其他节点中。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。