CAP定理与服务治理

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

 

Spring Cloud Eureka 实现的服务治理强调的事CAP 中的AP，即可用性和可靠性。Zookeeper则强调CP，一致性和可靠性。Eureka为了实现高可用，牺牲了一定的一致性，在极端的情况下，他宁愿接受故障实例，也不要丢掉“健康的”实例，比如，当注册中心发生网络故障的时候，都无法接收到心跳，强调AP的服务治理中会将所以故障实例剔除，但实际上这个只是因为注册中心网络故障，实际上客户端和服务实例还是可以通信的，Eureka则会因为超过85%的实例失去心跳而触发自我保护机制，注册中心会依旧保留所有节点，以实现服务间依然可以进行相互调用的场景，即使其中有部分故障节点。可以启动重试机制。在 Camden SR2 之后的版本 开始，Spring Cloud整合了 Spring Retry来增强RestTemplate的重试功能