逐字解释CAP

只有静下心来才能学得扎实

CAP是什么

• CAP 中的 C 是 一致性（Consistency），A 是可用性（Availability），P 是分区容错性（Partition tolerance）
  • 分区又是什么：在分布式网络中，不同的系统之间一旦失去通信，就会被分割成不同的孤岛，也就是不同的区域，这就是分区。
  • 那容错呢：错就是造成分区的原因，可能是网络故障，或者其他原因，容错是对系统说的，就是说就算发生了网络故障，也要包容它，并保证系统继续对外提供服务，也就是保证 A 或 P。
  • 所以分布式系统一定得是P的，如果不是 P 的，除非不是分布式服务。
  • A：可用性，任何时刻，对于客户端的请求能立刻返回结果，保证可以使用。
  • C：一致性，数据在多个服务实例之间是一样的，客户访问哪个返回的数据结果一样，是强一致性（相对BASE理论）。
• CAP定理，指的是在分布式系统中，C, A, P 这三个系统最多只能满足其中的两个。对于分布式系统，分区是客观存在的，也可以说是 A P 二选一。
  • 如果选择了 C，那系统可能会出现短时不可用，但是可用的时候，数据一定是一致的。
  • 如果选择了 A，那系统不会出现不可用的情况，但是可能同时多次请求的结果会不一致（在数据同步的过程中）。
    

举个例子–为什么不能三者兼得

背景

假如现在有两个分区N1和N2，N1和N2分别有不同的分区存储D1和D2，以及不同的服务S1和S2。

场景

1. 首先用户访问了N1，修改了D1的数据。
2. 用户再次访问，请求落在了N2。此时D1和D2的数据不一致。
3. 此时服务如何返回，就决定了是选 A 还是 P。

分析

• 此时 S1 和 S2 的数据不一致，由于网络阻塞的时间是不确定的，也就是说 S1 和 S2 之间的数据同步时间不确定。
• 如果立刻返回结果，保证了可用性，但是此时数据不一致，无法满足 一致性
• 如果等系统同步完成后再返回结果，保证了一致性，但是可能超时导致不满足可用性

CAP 取舍

• 对于多数大型互联网应用的场景，主机众多、部署分散，节点故障、网络故障是常态，必须保证P；应用的目的是提供服务，因此通常也要保证A。既然要保证P和A，就只能不同程度的舍弃C，牺牲一些用户体验。严格来讲，部分应用的A也不必保证100%，因此，主流做法是首要保障P、在A和C之间取舍、重A轻C。
• 但是，对于金融服务，必须保证C；大规模金融服务几乎必然涉及网络分区，所以也要保证P；为了保证C、P，只能牺牲A（停止服务）。对于某些特殊的金融服务，需要7*24小时提供服务，则改为牺牲部分P（如单节点主从备份，故障切换），保障C、A。

注册中心应用

微服务中常用的注册中心有ZooKeeper、Eureka、Nacos。那么它们分别满足 CAP 中的哪几个原则呢？

• zookeeper: 满足 CP，当节点选举的时候，无法提供服务，即不保证A
  • 选举过程：待补充
• euraka: 满足 AP，只有有一个节点，都会返回结果，但是结果可能不是最新的
• nacos: AP 和 CP 都支持
  • 如何切换两个模式，实现原理：待补充

参考文章

• https://cloud.tencent.com/developer/article/1882578
• https://monkeysayhi.github.io/2018/03/09/%E5%88%86%E5%B8%83%E5%BC%8F%E7%90%86%E8%AE%BA%EF%BC%9ACAP%E3%80%81BASE%E4%B8%8EACID/

相关问题

• CAP 是什么
• CAP 都有哪些组合模式，各有啥优缺点
• 微服务注册中心是用的哪些组合模式