一文道尽分布式的CAP原则

Myth丶恋晨 2023-01-20 09:37 54阅读 0赞

### 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算法)

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDYyNTY3_size_16_color_FFFFFF_t_70]

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

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

--------------------

## AP模型 ##

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

例如：同样一个更新操作  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDYyNTY3_size_16_color_FFFFFF_t_70 1]

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][RocketMq_-NameServer_1]

### Zookeeper ###

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDYyNTY3_size_16_color_FFFFFF_t_70]: /images/20221021/cc4cbc0c52bf4e7c8ba521d18c20a61b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDYyNTY3_size_16_color_FFFFFF_t_70 1]: /images/20221021/3cd2143f846b463bab07d5135f3e6ae9.png
[RocketMq_-NameServer_1]: https://keepgoon.blog.csdn.net/article/details/115659114