分布式事务：CAP理论详细介绍及发展历史

时间线

可以说Eric Brewer是CAP理论和BASE理论之父 

 事务全局图

分布式事务章节

事务：分布式事务与本地事务的区别-CSDN博客

分布式事务：CAP理论详细介绍及发展历史-CSDN博客

分布式事务：BASE理论详细介绍及发展历史（Eric Brewer，Dan Pritchet）-CSDN博客 

分布式事务：2PC与3PC的区别-CSDN博客

分布式事务：X/Open DTP分布式事务处理模型与分布式事务处理XA规范-CSDN博客

分布式事务：2PC，XA协议与Java事务当中JTA,JTS的关系-CSDN博客

简介

CAP定理

 2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在“ACM 分布式计算原理研讨会（PODC）”上提出的一个CAP猜想，这时候才广为人知。

 2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch，用严谨的数学推理证明了 CAP 猜想。自文章发布之后，CAP 正式从猜想变为分布式计算领域所公认的著名定理。

 Eric Brewer的2004年上课的PPT的CAP定理（里面有BASE理论）地址：https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

CAP定理证明地址：BrewersConjecture-SigAct.pdf (nus.edu.sg)

Brewer2.pdf (mit.edu)Seth Gilbert 和 Nancy Lynch关于Cap的另一文章：Brewer2.pdf (mit.edu)

 BASE理论

1997年，Eric Brewer和他的学生们在《Cluster-Based Scalable Network Services》文章中提出了BASE的概念， 包含Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）。

2004年，Eric Brewer上课的时候会进行对CAP和BASE进行讲解。

2008年5月（ACM杂志上写了5月，其他有的写了7月，我按照最早的时间来），eBay的Dan Pritchett发表了《Base: An Acid Alternative》推广了BASE理论，可以说，此时BASE理论才被广泛的认识到。

1997年的ACM文章：Cluster-based scalable network services (acm.org) 

 Dan Pritchet的base理论说明 BASE: An Acid Alternative (acm.org)

SOSP

ACM Symposium on Operating Systems Principle，ACM操作系统原理研讨会

两年一度的ACM操作系统原理研讨会是世界上首屈一指的操作系统技术研究人员、开发人员、程序员、供应商和教师论坛。学术界和行业参与者提交的研究和经验论文涵盖了全方位的理论和实践。（介绍说明翻译）

ACM的数字图书馆连接：About ACM DL

PODC

Principles of Distributed Computing,分布式计算原理研讨会（PODC）

PODC是一个专注于分布式系统的理论、设计、规范和实现研究的会议。PODC由ACM、SIGACT和SIGOPS赞助。PODC征集分布式系统所有领域的论文。我们鼓励从理论或实验的角度提交涉及分布式计算任何方面的意见书。提高对分布式计算原理的理解是我们共同的目标。感兴趣的主题包括分布式系统中的以下主题：*分布式算法：设计和分析，*通信网络：体系结构、服务、协议、应用程序，*多处理器和多核体系结构和算法，*共享和事务存储器、同步协议、并发编程，*容错、可靠性、可用性，自组织，*互联网应用程序、社交网络等（介绍说明翻译）

CAP详细介绍

ACID及限制

在数据库事务的ACID（原子性、一致性、隔离性和持久性）四大特性确保了单个数据库内部事务处理的可靠性，但在分布式系统环境下，由于网络延迟、节点故障以及数据复制等因素，ACID特性无法直接应用于跨多个数据库或服务的分布式事务。传统的ACID模型在分布式场景下可能导致性能下降或者可用性的损失。

为了解决分布式事务中的挑战，理论和实践上出现了多种新的解决方案和理论框架：

1. CAP定理：

   Eric Brewer教授提出了CAP定理，表明在分布式系统中不可能同时满足一致性（C）、可用性（A）和分区容错性（P）这三个要求，在设计时必须有所取舍。

2. BASE理论：

   BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）的缩写。它放宽了对一致性的要求，强调在分布式系统中可以容忍一定程度的数据不一致，但保证最终数据会达到一致状态。

CAP定理

2000年7月，在ACM Symposium on Principles of Distributed Computing（PODC）会议上，加州大学伯克利分校的Eric Brewer教授提出了著名的CAP猜想。

两年后，即2002年，麻省理工学院的研究人员Seth Gilbert和Nancy Lynch在理论上正式证明了这一猜想，他们发表的论文《Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services》为CAP猜想提供了严格的数学证明。自此，CAP猜想被确认为分布式计算领域的一个重要定理，也称为CAP定理。

CAP定理指出，在分布式计算系统中，特别是在设计基于网络（如Web服务）的分布式存储系统时，不可能同时满足以下三个理想属性：

1. 一致性（Consistency）：保证在数据更新后，所有后续访问都能读到最新值，即在任何给定的时间点，所有副本中的数据都是一致的。

2. 可用性（Availability）：每个请求都会收到一个响应，且该响应不会过期或包含错误信息（非超时或失败）。这意味着系统总是能够提供服务，即使在部分故障发生时也能返回有意义的数据。

3. 分区容错性（Partition tolerance）：即使在网络分区（节点间通信中断）的情况下，系统仍然能够继续操作而不至于整体失效。在大规模分布式系统中，由于网络延迟、断开连接等问题，分区容错通常是一个必然的要求。

根据CAP定理，在面临网络分区的情况下，系统设计者必须做出选择，只能保证上述三者中的两个属性。实际应用中，往往通过权衡和折衷来适应不同的业务场景需求。例如，有些系统会选择CA而牺牲P，适用于不太可能出现网络分区或者可以容忍短暂不可用的情况；另一些则选择AP，允许在特定时间内一定程度的数据不一致，以保持服务的高可用性和分区容错能力。

CAP理解

1、一致性

 在分布式环境中，数据一致性要求系统中的所有副本在同一时刻看到相同的数据状态。这意味着当一个更新操作成功完成并返回给客户端时，这个更新应该已经被系统中涉及的所有相关节点认可和应用，确保任何后续读取请求都能得到最新且一致的结果。

对于电商系统这类应用场景来说，数据的一致性至关重要。比如用户下单操作涉及到多个子事务，包括库存减少、支付订单新增，用户账户扣款等，这些操作必须作为一个整体原子地完成。只有当所有的子事务均执行成功，并且系统的全局状态反映出了这次下单的所有结果后，才能认为该次操作满足了数据一致性要求。如果因为网络延迟、节点故障或并发控制不当等原因导致部分操作生效而其他操作未完成，那么系统就处于不一致的状态，这可能会引发业务逻辑错误或者用户体验下降等问题。因此，在分布式系统设计时，通常会采用各种策略和技术（如分布式事务、一致性协议等）来最大程度地保证数据一致性。

数据一致性可以按照不同标准和应用场景细分为多种类型，以下是几种主要的数据一致性模型：

1. 强一致性（Strong Consistency ）：

   在强一致性模型（也称为线性一致性Linearizability）中，任何对数据的更新操作一旦完成，在所有后续的读取请求中都能立刻看到这个更新结果。这意味着在分布式系统中的所有节点上，数据的变化就像是在一个全局时钟下的瞬时同步。

2. 顺序一致性（Sequential Consistency）：

   保证所有节点上的操作看起来像是按照某种全局顺序执行的，尽管实际的操作可能并发进行。每个节点看到的操作顺序与全局顺序一致。

3. 因果一致性（Causal Consistency）：

   如果一个事件A在事件B之前发生，并且两个事件发生在不同的节点上，那么所有观察到事件A的节点也必须以相同的顺序看到事件B。这种模型允许并行修改没有因果关系的数据项。

4. 弱一致性（Weak Consistency）：

   不保证节点之间数据的立即同步，通常不提供任何关于何时可以看到更新的具体时间窗口。用户可能会看到过时的数据。

5. 最终一致性（Eventual Consistency）：

   系统最终会达到一致性状态，即所有的节点最终都会看到相同的数据版本，但无法保证达成一致的时间点。这是一种较弱的一致性模型，适用于某些高可用性和可扩展性要求较高的场景。

2、可用性

在分布式系统中，可用性是指系统能够持续响应用户请求并在合理的时间内返回有效结果的能力。

具体来说：

1. 响应时间（有限时间内）：

   可用性要求系统对用户的操作请求必须具有及时响应的能力。这意味着每个请求都应在预设的服务级别协议（SLA）规定的时限内得到处理并返回结果。如果超过了这个响应时间限制，用户体验会显著下降，甚至可能导致用户认为系统不可用。

2. 正常结果反馈（返回正常结果）：

   系统在完成用户请求的处理后，应明确无误地将处理结果返回给用户。无论请求是否成功执行，系统都应该提供一个有意义且易于理解的响应，而不是抛出错误或异常信息让用户感到困惑。例如，在下单操作中，即使涉及到复杂的分布式事务处理，系统也应当尽可能优化流程以确保快速响应，并在完成后告知用户下单是成功还是失败，以及可能的失败原因（如库存不足、支付失败等）。只有这样，才能确保系统的可用性，让用户始终能获得清晰的反馈和良好的使用体验。

3、分区容错性

当分布式系统的节点分布在不同的子网络或地理位置时，由于不可预知的原因（如网络故障、路由问题、数据中心断电等）可能导致这些子网络之间的通信中断，形成网络分区。尽管如此，一个具备分区容错性的分布式系统应当能够在这种情况下保持运行，并对外提供服务。

分区容错性意味着即使面临网络分区的挑战，分布式系统也应该具备以下能力：

1. 数据复制与同步：

   分布式系统中的数据通常需要在多个节点上进行复制，以确保即使某个子网络出现故障，其他子网络的节点也能提供服务。同时，必须有机制来保证数据在正常情况下的一致性和在网络分区期间及恢复后的最终一致性。

2. 故障检测与隔离：

   快速识别出网络分区以及受影响的服务或节点，并能够将这些部分从全局服务视图中隔离出来，以免影响整个系统的运行。

3. 事务处理与协调机制：

   对于涉及跨多个节点的事务操作，需采用适合分布式环境的事务模型，例如两阶段提交、三阶段提交、柔性事务（如TCC、Saga）等，或者采用事件驱动、最终一致性的方法来保证事务尽可能完成。

4. 冲突解决策略：

   在网络分区导致的数据不一致问题上，设计合理的冲突检测和解决策略至关重要，以便在分区恢复后能有效整合各个分区的数据。

5. 冗余与自我修复能力：

   构建具有冗余结构的系统组件，当某一部分失效时，备份资源可以立即接管服务，同时通过自动化的监控和恢复机制使系统在条件允许时自行恢复正常状态。

6. 网络通信协议与算法优化：

   选择或开发能够在网络不稳定条件下仍能较好工作的通信协议与算法，比如使用心跳检测、Gossip协议等手段维护节点间的状态信息交换。

7. 业务逻辑与数据模型适应性：

   设计灵活的业务逻辑与可扩展的数据模型，使得它们能在一定程度上容忍数据延迟更新或短暂不一致的情况。

综上所述，分区容错性是分布式系统设计中的一项关键指标，它要求系统能够在面对网络分区等极端情况时，通过合理的设计和技术手段，尽可能地维持业务连续性和数据完整性。

CAP的应用

1、CP场景，放弃A

分布式系统在设计时选择追求数据一致性（C）与分区容错性（P），并暂时牺牲可用性（A），那么在网络分区或其他故障发生时，系统的响应策略可能会采取以下方式：暂停服务，阻塞等待，分布式事务协调，进而会有一段时间可能不会提供服务。

比如中间件Zookeeper实现了CP而放弃了A。

用实际业务例子来说明，用之前举例的例子：

用户下单：用户下单后，对应的订单服务，库存服务，支付服务需要整体进行操作。如果一个失败了，其他两个服务也必须进行回滚。

2、AP场景，放弃C

分布式系统在设计时更侧重于可用性（A），而暂时牺牲数据一致性时，系统会采取一些策略来确保服务持续可用，即使在网络分区或其他故障发生时。那么系统采用最终一致性模型，在某个时间窗口之后，所有节点上的数据将最终达到一致状态。在此期间，由于数据同步和复制的延迟，不同节点可能提供不同的数据视图。系统通常会对数据进行版本管理，并设计冲突检测与解决机制，在数据最终同步的过程中处理可能出现的冲突情况，也有通过事件驱动架构或者TCC（Try-Confirm-Cancel）等柔性事务模型，可以在保持高可用性的同时，尽量减少数据不一致的时间窗口，并在后期通过补正措施使得数据达成一致。

比如中间件Redis和RocketMQ属于CAP里面的AP，优先去保证高可用.

用实际业务例子来说明，还是之前的下单业务例子

用户下单了，并且支付完成，订单服务进行了订单新增，库存服务已经进行了库存扣减，然后支付服务的支付订单已经支付。然后给用户一个提示说“订单已支付，需要等待银行回馈”。可能等待个1分钟（长的可能1天），就正式结束了。在这个过程中，可以看到数据在用户支付完成之后，是不一致的，但是在银行确认后并且发出回馈通知之后，才正式达到数据一致。对于系统使用的用户来讲，系统是可用的。

3、CA场景，放弃P

一个分布式系统在设计时选择放弃分区容错性（P），意味着它无法有效应对网络分区的情况。在网络分区发生时，为了保持数据一致性或可用性，系统可能需要牺牲一部分节点的服务能力，或者整体服务暂时不可用。

这样的设计将导致以下结果：

1. 单点故障：系统可能会依赖于单一的数据中心或通信链路，一旦这些基础设施出现故障，整个系统可能因此而瘫痪。

2. 可扩展性受限：由于放弃了分区容错性，系统无法有效地跨多个地理位置或子网络部署，这将严重限制系统的水平扩展能力，难以随着业务增长和用户规模扩大而灵活地增加资源和服务能力。

3. 高风险与低可靠性：在真实世界中，网络故障、硬件损坏等情况是无法完全避免的。放弃分区容错性的系统面临更高的风险，其服务质量和可用性受到极大影响。

4. 不满足大规模互联网应用需求：对于许多大型互联网应用来说，容忍网络分区并实现分区容错性是基本要求。若放弃这一特性，系统很难在实际场景中提供稳定可靠的服务。

放弃分区容错性的分布式系统实际上会限制自身的弹性、稳定性和可扩展性，使其在面对现实环境中常见的网络问题时显得脆弱不堪，不适合用于构建高度可用且可扩展的大规模分布式应用。

下单业务，考虑分区容错性，增加订单应当是这样的：

不考虑分区容错性，如果是单点服务的：

这种情况下，很明显，不会有公司会采用这种方式的。 

CAP 该怎么权衡

根据刚才的三个场景，P也就是分区容错性一定是需要的。那么在一致性（C）和可用性（A）之间怎么权衡，能否一起存在。

1.在CP的情况下，同时保证A

用户下单失败了，原来CP下，需要同时失败，但是按照可用性来讲，需要让其他正常的操作暂停或者不回滚，这样数据就会不一致，就跟一致性冲突了

2.在AP的情况下，同时保证C

用户下单后，原来AP情况下，如果大金额的支付，等待银行反馈假如需要等待2个小时，按照一致性来讲，整个流程数据一致，代表2个小时内不会返回给用户结果，通常2个小时也意味着请求超时。这样的结果就跟可用性冲突了。

所以在分布式系统中采用的分布式事务控制，我们根据自身的业务需要来确认需要哪种。

CAP和ACID中的A和C的区别

A区别

ACID中的A指的是原子性(Atomicity)，是指事务被视为一个不可分割的最小工作单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。

CAP中的A指的是可用性(Availability)，在分布式系统中，可用性是指系统能够持续响应用户请求并在合理的时间内返回有效结果的能力。

C区别

ACID一致性（Consistency）是有关数据库规则，数据库总是从一个一致性的状态转换到另外一个一致性的状态。

CAP的一致性（Consistency）是在分布式环境中，数据一致性要求系统中的所有副本在同一时刻看到相同的数据状态。这意味着当一个更新操作成功完成并返回给客户端时，这个更新应该已经被系统中涉及的所有相关节点认可和应用，确保任何后续读取请求都能得到最新且一致的结果。

总结