CAP定理与服务治理

青旅半醒 2022-01-06 04:13 192阅读 0赞

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

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

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

分区容忍性（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的重试功能

[Link 1]: https://baike.baidu.com/item/%E4%B8%80%E8%87%B4%E6%80%A7/9840083
[Link 2]: https://baike.baidu.com/item/%E5%8F%AF%E7%94%A8%E6%80%A7/109628
[Link 3]: https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/4905336
[Link 4]: https://baike.baidu.com/item/%E9%9B%86%E7%BE%A4/5486962
[Link 5]: https://baike.baidu.com/item/%E5%AE%A2%E6%88%B7%E7%AB%AF/101081