一文道尽分布式的CAP原则

Posted 2021-05-18 keep-go-on

CAP原则

• 什么是CAP原则
• • CP模型
  • AP模型
  • 必须三者取其二吗？
  • 行业应用实例
  • • Eureka
    • Nacos
    • RocketMQ
    • Zookeeper

---

什么是CAP原则

CAP原则是分布式里很重要的原则，具体如下：

1. C（Consistency）一致性原则: 对于一个写操作，在任何一个节点都应当可以正确的读到该数据，各个节点都需要保证数据的一致性。
2. A (Availability) 可用性：对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使出现节点失效。
3. P (Partition tolerance) 分区容错性 : 能容忍网络分区，在网络断开的情况下，被分隔的节点仍能正常对外提供服务,简而言之，部分服务宕机不会影响整体的正确性。

例如一个服务有两个副本，如果两个副本中间网络出现问题导致不能通信，那么会出现如下情况：

1. 如果一个副本更新成功就返回成功，那么就保证了服务的可用性（A）,但是牺牲了一致性(C)，因为另一个副本没有得到更新。
2. 如果必须等到两个副本都执行了更新命令，才会返回服务结果。这样可以保证一致性(C)，但是牺牲了可用性(A)
3. 如果一个副本更新成功返回成功，但是记录本次未同步的副本，等到副本直接通讯恢复，再执行数据同步，这样保证了可用性，保证了最终一致性,但存在了副本之间一段时间内的数据不一致（很多AP模型都是采用了这种方式保证最终一致性）。

著名的一致性算法 Paxos ， ZAB ，Raft 等

CP模型

常见的CP模型： zookeeper(ZAB算法)

例如：数据库含有主从节点。

1. 客户端发起更新命令
2. 主数据库发起同步数据命令，然后等待从库更新。
3. 从数据库更新完成，告知主数据库数据同步完成。
4. 主数据库得到从数据库的更新结果，然后告知客户端数据库更新完成。

以上流程是一个简单的CP模型，它保证了数据的一致性。但是如果从节点这时与主节点是不能通信的，也就是说数据第二步的同步请求是无法发送的，自然也无法得到从节点的返回，这样主数据库就会返回客户端失败，丢失了可用性。

---

AP模型

常见的AP模型:Nacos(同时支持CP模型),Eureka

例如：同样一个更新操作

1. 客户端发送更新命令。
2. 主数据库异步调用从数据库更新，但是不等待从数据库返回，直接将更新结果返回给客户端。

以上流程中如果从数据库与主数据库不能通信，依旧可以保证数据库可用，保证了可用性,但是丢失主从数据库之间的一致性.

必须三者取其二吗？

其实并不是，自古忠孝难两全，但是那是指定特殊时期，和平时期是可以保证忠孝两全的。

1. 副本不能通信造成分区的情况很好发生，在不存在分区问题时C和A都是可以保证的。
2. 即便发生了分区问题，服务治理算法也可以做部分分区可用，故障分区停用，保证可用分区的一致性和可用性。牺牲掉部分故障分区，但是依旧能保证整体的C和A。
3. 另外一致性和可用性并不是水火不容的关系，而是在故障时更倾向于保证什么而已。

行业应用实例

以下是当前主流技术栈对CAP原则的支持。一下实例可以发现，CAP原则如何选择在于它们应对的场景，CP模型和AP模型本质并没有优劣的区别。只是它们在解决不同的问题，它们的解决方案绝对它们应该去使用那种模型。

---

Eureka

Eureka使用AP模型，保证可用性作为首要条件。Eureka是服务发现中心，中心存在宕机时间，对服务提供服务有很大影响。另外Eureka客户端会对一致性做一次筛选，因此在短时间内的数据不一致是不会出现问题的。

Nacos

阿里巴巴用来替代Eureka的产品，它默认使用AP模型，但是支持CP模型。其原因并不是Nacos更强大，而是它们解决的问题不同。Nacos不只是发现中心，也是配置中心(配置中心一致性是数据库保证的)，以后可能也会有更远大的设计目标，需要保证数据的强一致性。

RocketMQ

rocketMQ自己实现了一个服务治理服务NameServer，它采用了AP模型，原因是它只是个服务治理服务，它的实现相对简陋，应该说相当简洁，所以效率也相当的高，具体可以参考 ： RocketMq总决式-NameServer源码1

Zookeeper

zookeeper采用CP模型保证数据一致性。缺点存在服务拒绝服务间隔（选举），好处数据一致性。原因是：zookeeper还提供了分布式锁的功能，数据一致性是必须的。