今天，本文的主角是CAP理论。

在我开始阐述自己关于CAP理论的见解之前，首先要声明一点：CAP理论关注的侧重点是数据，不是系统，不是系统，不是系统。

1. 集中式系统与分布式系统

在互联网行业的发展过程中，很多网站、服务都会经历由最初简单的集中式系统，到后来复杂的分布式系统的过程。

那么，什么是集中式系统，什么又是分布式系统呢？

在网络的拓扑结构中，每一台服务器都是一个服务节点。而整个应用则包含了多台服务器，正是这若干个服务器节点组成了整个对外服务的应用。

实际的网络结构远比图示复杂，这里为了更好地讲解，进行了简化处理

如图所示，集中式系统中数据库服务器节点只有一台，而当数据进行访问、更新操作时都是同一节点，能够保证数据的一致性（数据库本身支持事务，事务也具有ACID特性）。

思考一个问题：有了集中式系统，为什么又需要分布式系统？

集中式系统的主要优点：

1. 配置简单、容易维护管理
2. 数据不会出现不一致性问题

集中式系统的主要缺点：

1. 单机硬件资源有限，数据存储有上限问题
2. 单机对外服务提供的访问量有限
3. 存在单点故障问题

2. 向上扩容与水平扩容

如今高速发展的互联网行业，稍具规模的公司数据量最少是上TB级别（不然都不好意思说自己是大型公司）。

对于这么大的数据量存储与维护来说，如果使用集中式的单机服务，则意味着需要向上扩容（使用最好的CPU、最大的内存、最好的硬盘），而向上扩容也会有一定的上限（举个例子：服务器如果使用32位操作系统，系统能够识别的最大内存为4G，即使安装8G内存条，也是浪费。网卡也有一定的带宽上限等等），成本很高（越大的内存、越快的固态硬盘价格越高昂）。

没有什么问题能难倒这群整天在写bug的最可爱的人，既然向上扩容存不行，那么就来个水平扩容。

水平扩容，用一句通俗的话讲就是堆积机器。

如果相同的预算，有两套方案：

1. 向上扩容
2. 水平扩容

最终的结果，绝对是水平扩容能够对外提供的访问请求量更大。

有了水平扩容就出现了分布式系统，原来业务只需要部署到一台服务器节点上，现在则需要部署到多台节点上。

与集中式系统相比，还拿数据库还说，分布式系统中数据库服务器节点有多台，进行的数据访问、更新操作会随机地落到某一台节点。为了保证数据在某一台节点上更新之后，能够在另外一台节点上访问到，就需要进行数据同步操作。

那么分布式系统的问题又来了，如何同步？同步失败怎么办？

分布式系统的主要优点：

1. 理论上可以无限水平扩容，存储更多数据
2. 可以提供更多服务请求
3. 数据备份、容灾

分布式系统的主要缺点：

1. 网络拓扑结构复杂，维护管理复杂度高
2. 数据需要在不同节点之间进行同步，同时存在同步失败的风险
3. 数据不能在同一时刻在所有节点保持一致，存在不一致性问题

3. 大名鼎鼎的CAP

面对集中式系统与分布式系统的上述问题，2000 年 Eric Brewer 教授提出CAP猜想。2年后，Seth Gilbert 和 Nancy Lynch 从理论上证明了猜想的可能性。从此，CAP 理论正式在学术上成为了分布式计算领域的公认定理，并深深地影响了分布式计算的发展。

一致性（C）：分布式系统中的所有数据节点，在同一时刻是否有同样的值（等同于所有节点访问同一份最新的数据副本）。

可用性（A）：保证每个请求不管成功或者失败都有响应。

分区容忍性（P）：各个节点数据不能在一定的时间内达到一致性，就认为出现了分区。分区容忍性就是在系统中任意信息的丢失或失败不会影响系统的继续运作。

遗憾的是，网络进行数据传输时由于数据一定会存在丢失、延迟问题（P），在分布式系统中无法同时得到这三个特性，而P是一定要选的，那么存在的选项只剩下两个了：CP、AP。

CP：满足一致性和容错性，舍弃可用性。

也就是说，如果在某一节点对某一条数据进行更新，此时在其他节点有用户访问了该数据，用户的访问会出现阻塞、错误等情况，直到该数据被同步到所有或者大于某些阈值的节点（想想实际生活中使用银行类APP时的一些情况）。

AP：满足可用性和容错性，舍弃一致性。

也就是说，如果在某一节点对某一条数据进行了更新操作，在数据没有被同步到其他所有节点之前，允许其他用户访问某些节点上该数据的旧值（想想实际生活中，抢火车票时，你看到有几张剩余的票，但是下单时却提示没有多余票）。

CA：满足一致性和可用性，舍弃分区容错性。

此种情况就是抛弃了分布式系统，而选择了集中式系统（单机数据库就是个很好的例子）。

4. 强一致性与最终一致性

虽然说数据一定会存在丢失、延迟问题，但是该问题也不是时刻存在发生的，在整个网络请求交互中只占了很小一部分比例。

为了更新提供服务以及用户体验，大部分业务不需要绝对严格的数据强一致性，只需要做到最终一致性即可。这个时候又出现了另外一个理论BASE，BASE 理论可以看做是对CAP理论的补充。

基本可用（Basically Available）: 当整个系统出现了不可预知的故障，保证核心业务能够对外提供服务，部分非核心服务可能会进行降级处理。

软状态（Soft State）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性（Eventually Consistent）：系统允许存在中间态，但是需要在一定的时间内通过某些手段达到最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

5. 怎么选择

面对分布式系统，又是CAP，又是BASE。在实际的开发过程中，应该怎么选择？构建什么样的系统呢？

这里需要提醒一点，还记得文章开始时说过的一句话吗？CAP关注的是数据。至于如何选择，要看这些数据对你的重要程度。

假如：现在做的是一个新闻、电商商品搜索服务，完全可以选择AP。

因为，用户对这些数据的变更并不会太敏感，也允许存在一定时间的延迟，只要达到最终一致性即可（日常生活中，当你跟家人同时刷某一款APP时，绝对会发现显示的内容会存在一定差别，但是会在很短时间内显示一致）。

假如：现在要做的是一个银行资金理财账号系统，则需要谨慎地选择CP。

因为，此时用户对这些数据的变更会十分敏感，不允许出现一点差错，但是有时候也会存在支付中这种中间态（比如今天理财在17:00:00点关闭，我在16:59:59购买理财，也提示我购买成功，但是第二天登录账号时发现购买成功时间是昨天的17:00:01秒，中间差了一天的收益，这个怎么算？当然，实际生活中，银行转账时也可能会提示你转账会出现一定延迟之类的信息）。面对CP，很多时候不是严格的强一致性，而是最终一致性，要看具体的业务与场景。

6. 总结

业务场景千千变、玩法套路也不断。但是，这一切都是构建在一定的理论基础与框架之内。只有掌握了这些理论，在架构设计与实现的时候，才能够更好的找到一套适合自己的方案。

今天讲解了集中式系统、分布式系统、CAP理论、BASE理论，但是有一点需要再次说名一下，这些理论的侧重点都是数据。在设计架构时，需要根据数据的重要性，来选择架构。而不是先设计架构，然后在架构里面设计方案来满足数据的要求。

- THE END -

关注加星标，了解「编程技术之道」