浅析分布式Cap定理和Base理论！

作者：码农二胖 2020-10-16 06:36:57

系统

分布式 根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。

 [[346602]]

引言

在理论计算机科学中，CAP定理(CAP theorem)，又被称作布鲁尔定理(Brewer’s theorem)，它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性(Consistency) (等同于所有节点访问同一份最新的数据副本)
• 可用性(Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
• 分区容错性(Partition tolerance)(以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择)

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

这个定义读下来是不是让人看的一脸懵逼，多读几遍是不是又会觉得有那么点明白了。CAP 理论听起来十分抽象，本文尝试以生活中的例子并用通俗易懂的语言来解释 CAP 理论的含义。

CAP小故事

这个故事感觉讲的还是挺有意思的，大家点击链接https://zhuanlan.zhihu.com/p/265670196进去看看或者点击阅读原文进行阅读。相信看了这个小故事之后，再来看看前面的定义可能会觉得 更好理解了。

Cap的权衡

通过CAP理论我们可以无法同时满足一致性、可用性和分区容错性这三个特性，那么我们需要怎么权衡呢?

选择CA放弃 P

这种情况的话在分布式系统中基本是不可能存在的。因为在分布式环境下分区是必然的，如果我们要舍弃P就意味着我们要舍弃分布式系统，所以也就没必要再来讨论CAP理论了，

选择CP放弃A

一个分布式系统如果不能做到可用性，经常宕机或者停止提供服务的话，这样的话用户体验是非常差的，就像曾经的“微盟删库事件”，只有等到所有的数据都被找回来才会继续对外提供服务，这期间停机多久，给商家造成了的多大的损失。我们常见的CP分布式系统有分布式数据库(redis)等，以及Zookeeper等都是优先保证数据的强一致性，来舍弃系统的可用性。

放弃AP放弃C

如果要保证高可用并允许分区，则需要放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现如今应该大多数场景都是会选择可用性，而去牺牲一致性(保持最终一致性)，就像我们春节抢红包的时候，它不会立马告诉你抢了多少金额，只是提示你过多久再去查看。以及我们春节抢票的时候，明明看到这辆高铁还是邮票的但是等你填完验证码，以及乘客信息真正提交订单的时候就告诉你没票了，你再返回列表页查看该车次的时候，也还继续显示着有票 。这些虽然用户体验有那么一丢丢的不友好，但是也能接受。

小结

CAP的选择的话没有哪种更好，只有根据自己的业务场景来选择，选择适合自己的才是最好的。

Base理论

BASE：全称：Basically Available(基本可用)，Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写，来自 ebay 的架构师提出。Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既是无法做到强一致性(Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

Basically Available(基本可用)

什么是基本可用?牺牲性能(服务响应时间)、体验(部分功能体验)以保证基本可用。牺牲性能：比如我们查询商品正常情况响应时间都是1s左右返回结果，但是基本可用的话返回结果都是10s返回结果。牺牲体验：比如双十一的时候，淘宝只会保证核心功能可用(下单、支付等)，其他非核心(退货、修改地址等)的功能都会进行降级，关于降级可以看下以前这个文章《高并发系统三大利器之降级》

Soft State(软状态)

允许不影响整体可用性的中间状态 即允许系统在多个不同节点的数据副本存在数据延时。

Eventual Consistency(最终一致性)

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

结束

由于自己才疏学浅，难免会有纰漏，假如你发现了错误的地方，还望留言给我指出来,我会对其加以修正。

本文转载自微信公众号「 java金融」，可以通过以下二维码关注。转载本文请联系java金融公众号。