【进阶架构师】分布式之CAP原则

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

在学习分布式相关知识以及分布式相关框架Kafka、Redis等时，常常会看到CAP原则，就是要么AP，要么CP，要么AC，但是不存在CAP。但是在网上搜索CAP相关文章时，介绍也都基本大同小异，比较官方，不容易理解，本文试图用比较白话通俗的方式来介绍CAP原则，以及相关分布式框架使用了CAP中的什么原则。

---

一、官方CAP原则定义

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。
一致性（C）： 在分布式系统中的所有数据备份，在同一时刻是否同样的值，即写操作之后的读操作，必须返回该值。（分为弱一致性、强一致性和最终一致性）
可用性（A）： 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

二、通俗CAP解释

1.一致性（C）

当一台服务写入数据之后，访问其他服务器时，是否都能访问到最新的数据，为了保证一致性，服务器需要时间同步复制数据，直到所有的数据都一致之后才能对外提供服务（这个时间内影响可用性）。

2.可用性（A）

可用性就是分布式集群出现单点故障，不能够对外提供服务，或者请求超时的情况。

3.分区容忍性（P）

分区容错性，就是CAP中的P，这一项其实是必选项，做了分布式，就会有多台服务器之间通信，通信就会有网络问题产生分区（比如本来5台服务器可以相互通信，现在变成其中2台之间可以通信，另外3台之间可以通信，这个2台和另外3台之间不能通信，但是这2台和3台对外还是可以正常提供服务）。比如数据库的主从配置。如果不要P，那只是个单机服务，就不需要CAP来指导了。

三、最终一致性解决方案BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

Basically Available（基本可用）：
基本可用指的是分布式系统在遇到故障或者系统出现高并发的情况下降低一定的可用性
响应时间损失：例如请求返回要慢点平时0.5秒，现在1秒。
系统功能缺失：双十一活动期间出现等待页面，非核心业务部分页面降级处理，把资源给核心功能。

Soft state（软状态）：允许系统存在中间状态，系统同步允许一定的延迟

Eventually consistent（最终一致性）：系统中所有数据副本，在经过一段时间的同步之后，最终能够打到一个一致的状态，不要求实时。

四、常用分布式框架的CAP原则

CP without A：

设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
zookeeper:最好的例子就是zookeeper，如果客户端心跳消失的时候，zookeeper会很快剔除该服务，之后就无法提供需求；

AP wihtout C:

Eureka就是一个AP架构的例子，当Eureka客户端心跳消失的时候，那Eureka服务端就会启动自我保护机制，不会剔除该EurekaClient客户端的服务，依然可以提供需求；

CA without P:

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

---

总结

CAP原则，是任何在做架构设计或者研发中间框架时的出发点，真正了解CAP才能让你站在更高的视角去设计你的系统，让你的系统上线后稳定的对外提供服务。互联网分布式服务多数基于AP，Base模式也是基于AP组合。实现最终一致性的方案有TCC、消息队列、Saga等，其中消息队列用的最多。