本文内容整顿自博学谷狂野架构师
CAP 定理又被称作布鲁尔定理，是加州大学的计算机科学家布鲁尔在 2000 年提出的一个猜测。2002 年，麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜测的证实，使之成为分布式计算畛域公认的一个定理。
布鲁尔在提出CAP猜测时并没有具体定义 Consistency、Availability、Partition Tolerance 这3个词的含意，不同材料的具体定义也有差异，为了更好地解释，上面抉择Robert Greiner的文章《CAP Theorem》作为参考根底。
CAP实践的定义
在一个分布式系统（指相互连贯并共享数据的节点的汇合）中，当波及读写操作时，只能保障一致性（Consistence）、可用性（Availability）、分区容错性（PartitionTolerance）三者中的两个，另外一个必须被就义。
Consistency、Availability、Partition Tolerance具体解释如下：
C - Consistency 一致性
A read is guaranteed to return the most recent write for a given client.
对某个指定的客户端来说，读操作保障可能返回最新的写操作后果。
这里并不是强调同一时刻领有雷同的数据，对于零碎执行事务来说，在事务执行过程中，零碎其实处于一个不统一的状态，不同的节点的数据并不完全一致。
一致性强调客户端读操作可能获取最新的写操作后果，是因为事务在执行过程中，客户端是无奈读取到未提交的数据的，只有等到事务提交后，客户端能力读取到事务写入的数据，而如果事务失败则会进行回滚，客户端也不会读取到事务两头写入的数据。
A - Availability 可用性
A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
非故障的节点在正当的工夫内返回正当的响应（不是谬误和超时的响应）。
这里强调的是正当的响应，不能超时，不能出错。留神并没有说“正确”的后果，例如，应该返回 100 但实际上返回了 90，必定是不正确的后果，但能够是一个正当的后果。
P - Partition Tolerance 分区容忍性
The system will continue to function when network partitions occur.
当呈现网络分区后，零碎可能持续“履行职责”。
这里网络分区是指：
一个分布式系统外面，节点组成的网络原本应该是连通的。然而可能因为一些故障（节点间网络连接断开、节点宕机），使得有些节点之间不连通了，整个网络就分成了几块区域，数据就分布在了这些不连通的区域中。
一致性、可用性、分区容忍性的抉择
尽管 CAP 实践定义是三个因素中只能取两个，但放到分布式环境下来思考，咱们会发现必须抉择 P（分区容忍）因素，因为网络自身无奈做到 100% 牢靠，有可能出故障，所以分区是一个必然的景象。
如果咱们抉择了 CA（一致性 + 可用性） 而放弃了 P（分区容忍性），那么当产生分区景象时，为了保障 C（一致性），零碎须要禁止写入，当有写入申请时，零碎返回 error（例如，以后零碎不容许写入），这又和 A(可用性) 抵触了，因为 A（可用性）要求返回 no error 和 no timeout。
因而，分布式系统实践上不可能抉择 CA （一致性 + 可用性）架构，只能抉择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中抉择。
CP - Consistency + Partition Tolerance （一致性 + 分区容忍性）
如上图所示，因为Node1节点和Node2节点连贯中断导致分区景象，Node1节点的数据曾经更新到y，然而Node1 和 Node2 之间的复制通道中断，数据 y 无奈同步到 Node2，Node2 节点上的数据还是旧数据x。
这时客户端C 拜访 Node2 时，Node2 须要返回 Error，提醒客户端 “零碎当初产生了谬误”，这种解决形式违
背了可用性（Availability）的要求，因而 CAP 三者只能满足 CP。
AP - Availability + Partition Tolerance （可用性 + 分区容忍性）
同样是Node2 节点上的数据还是旧数据x，这时客户端C 拜访 Node2 时，Node2 将以后本人领有的数据 x 返回给客户端 了，而实际上以后最新的数据曾经是 y 了，这就不满足一致性（Consistency）的要求了，因而 CAP 三者只能满足 AP。
留神：这里 Node2 节点返回 x，尽管不是一个“正确”的后果，然而一个“正当”的后果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据。
值得补充的是，CAP实践通知咱们分布式系统只能抉择AP或者CP，但实际上并不是说整个零碎只能抉择AP或者CP，在 CAP 实践落地实际时，咱们须要将零碎内的数据依照不同的利用场景和要求进行分类，每类数据抉择不同的策略（CP 还是 AP），而不是间接限定整个零碎所有数据都是同一策略。
另外，只能抉择CP或者AP是指零碎产生分区景象时无奈同时保障C（一致性）和A（可用性），但不是意味着什么都不做，当分区故障解决后，零碎还是要放弃保障CA。
CAP实践的延长——BASE实践
BASE 是指根本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即便无奈做到强一致性（CAP 的一致性就是强一致性），但利用能够采纳适宜的形式达到最终一致性。
BA - Basically Available 根本可用
分布式系统在呈现故障时，容许损失局部可用性，即保障外围可用。
这里的关键词是“局部”和“外围”，理论实际上，哪些是外围须要依据具体业务来衡量。例如登录性能绝对注册性能更加外围，注册不了最多影响散失一部分用户，如果用户曾经注册但无奈登录，那就象征用户无奈应用零碎，造成的影响范畴更大。
S - Soft State 软状态
容许零碎存在中间状态，而该中间状态不会影响零碎整体可用性。这里的中间状态就是 CAP 实践中的数据不统一。
E - Eventual Consistency 最终一致性
零碎中的所有数据正本通过肯定工夫后，最终可能达到统一的状态。
这里的关键词是“肯定工夫” 和 “最终”，“肯定工夫”和数据的个性是强关联的，不同业务不同数据可能容忍的不统一工夫是不同的。例如领取类业务是要求秒级别内达到统一，因为用户时时关注；用户发的最新微博，能够容忍30分钟内达到统一的状态，因为用户短时间看不到明星发的微博是无感知的。而“最终”的含意就是不论多长时间，最终还是要达到一致性的状态。
BASE 实践实质上是对 CAP 的延长和补充，更具体地说，是对 CAP 中 AP 计划的一个补充：
CP 实践是疏忽延时的，而理论利用中延时是无奈防止的。
这一点就意味着完满的 CP 场景是不存在的，即便是几毫秒的数据复制提早，在这几毫秒工夫距离内，零碎是不合乎 CP 要求的。因而 CAP 中的 CP 计划，实际上也是实现了最终一致性，只是“肯定工夫”是指几毫秒而已。AP 计划中就义一致性只是指产生分区故障期间，而不是永远放弃一致性。
这一点其实就是 BASE 实践延长的中央，分区期间就义一致性，但分区故障复原后，零碎应该达到最终一致性。
数据一致性模型
后面介绍的BASE模型提过“强一致性”和“最终一致性”，上面对这些一致性模型开展介绍。
分布式系统通过复制数据来进步零碎的可靠性和容错性，并且将数据的不同的正本寄存在不同的机器上，因为保护数据正本的一致性代价很高，因而许多零碎采纳弱一致性来进步性能，上面介绍常见的一致性模型：
强一致性
要求无论更新操作是在哪个数据正本上执行，之后所有的读操作都要能取得最新的数据。对于单正本数据来说，读写操作是在同一数据上执行的，容易保障强一致性。对多正本数据来说，则须要应用分布式事务协定。弱一致性
在这种一致性下，用户读到某一操作对系统特定数据的更新须要一段时间，咱们将这段时间称为"不一致性窗口"。最终一致性
是弱一致性的一种特例，在这种一致性下零碎保障用户最终可能读取到某操作对系统特定数据的更新（读取操作之前没有该数据的其余更新操作）。"不一致性窗口"的大小依赖于交互提早、零碎的负载，以及数据的正本数等。
总结
零碎抉择哪种一致性模型取决于利用对一致性的需要，所选取的一致性模型还会影响到零碎如何解决用户的申请以及对正本保护技术的抉择等。前面将基于下面介绍的一致性模型别离介绍分布式事务的解决方案。
柔性事务
柔性事务的概念
在电商等互联网场景下，传统的事务在数据库性能和解决能力上都暴露出了瓶颈。在分布式畛域基于CAP实践以及BASE实践，有人就提出了柔性事务的概念。
基于BASE实践的设计思维，柔性事务下，在不影响零碎整体可用性的状况下(Basically Available 根本可用)，容许零碎存在数据不统一的中间状态(Soft State 软状态)，在通过数据同步的延时之后，最终数据可能达到统一。并不是齐全放弃了ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。
实现柔性事务的一些个性
上面介绍的是实现柔性事务的一些常见个性，这些个性在具体的计划中不肯定都要满足，因为不同的计划要求不一样。
可见性(对外可查问)
在分布式事务执行过程中，如果某一个步骤执行出错，就须要明确的晓得其余几个操作的解决状况，这就须要其余的服务都可能提供查问接口，保障能够通过查问来判断操作的解决状况。
为了保障操作的可查问，须要对于每一个服务的每一次调用都有一个全局惟一的标识，能够是业务单据号（如订单号）、也能够是零碎调配的操作流水号（如领取记录流水号）。除此之外，操作的工夫信息也要有残缺的记录。
操作幂等性
幂等性，其实是一个数学概念。幂等函数，或幂等办法，是指能够应用雷同参数反复执行，并能取得雷同后果的函数。幂等操作的特点是其任意屡次执行所产生的影响均与一次执行的影响雷同。也就是说，同一个办法，应用同样的参数，调用屡次产生的业务后果与调用一次产生的业务后果雷同。
之所以须要操作幂等性，是因为为了保证数据的最终一致性，很多事务协定都会有很多重试的操作，如果一个办法不保障幂等，那么将无奈被重试。幂等操作的实现形式有多种，如在零碎中缓存所有的申请与处理结果、检测到反复操作后，间接返回上一次的处理结果等。
本文由
传智教育博学谷狂野架构师教研团队公布。如果本文对您有帮忙，欢送
关注和点赞；如果您有任何倡议也可留言评论或私信，您的反对是我保持创作的能源。转载请注明出处！