架构师训练营 CAP 原则

在软件发展过程中，单机系统无法满足系统的性能要求，从而衍生出了把业务拆分从而分开部署，独立提供服务能力的方式，这就是分布式系统，但因为系统分布式部署，从而也衍生出了一些问题，比如数据一致性，可用性等等，从而出现了CAP原则。



• C-一致性（Consistency）

一致性通常是指数据在分布式系统中保持一致，或者状态一致

• A-可用性（Availability）

可用性是指系统不会因为部分系统出现问题而导致整个系统的不可用

• P-分区容忍性（Partition tolerance）

分区指的是由于网络原因，导致将分布式系统分成了两部分，两部分互相不能通信，从而导致系统的不可用，而分区容忍性需要能够容忍这种分区问题。在现代的分布式系统中，网络分区问题是很普遍的，可能突然网络又问题，部分机器，或者节点就访问不通了，但不能因为这个节点不通 ，就让整个系统不可用，在分布式系统中，分区容错性是必须要保证的。



CAP原则是说一个分布式系统只能同时满嘴以上两种，而无法满足三种。



现在我们可以逐一分析

• 假设我们的分布式系统满足分区容错性，然后看是否能够满足一致性，假设场景A是一个下单的过程，这个过程需要有以下两个步骤。

• 需要在订单系统创建订单

• 需要在库存系统中扣减库存

订单系统和库存系统是分布式部署，那么这个操作要求要么订单下成功就必须扣减库存，要么就都不成功，不然数据就不一致了，那假设现在库存系统不可用，或者库存系统出现超时，那么我们的订单是不是就无法创建了呢？因为要保证数据的一致性。

所以这个系统就只能满足了CP，无法满足A。



• 假设我们的分布式系统满足分区容错性，然后看是否能够满足可用性，假设场景B是一个注册的过程，注册后需要发送一条短信，并记录短信发送记录。但是如果短信系统不可能或者超时的时候，要求不影响注册流程。而且短信并不要求立刻发，晚点再发也没关系。那么我们的发短信可能是一个异步的过程。这时候系统就没有要求一致性，那么也就满足了可用性。所以这个场景就是满足了AP，没有满足C。



• 最后假设我们不满足分区容错性，看能不能满足CA呢？首先网络出现分区，那么订单系统和库存系统之间的网络可能不通了，这时候如果我们为了保证数据的一致性，那么只能无法创建订单，那么系统也就不可用了。所以这时候只能满足一个C。那有没有可能满足A呢？比如第二个场景，我们的注册和短信发送系统之间的网络不通了，我们不要求C，这时候注册可用，系统也可用，但是上面又说我么不满足分区容错性，那其实就已经相反了，因为在系统可用的时候已经满足了分区容错性。



以上CAP原则实际上归纳的还是过于宽泛，现在更多的还是应用BASE理论。



• 基本可用（Basically Available）

• 软状态（Soft State）

• 最终一致性（Eventually Consistent）