在支付系统的核心架构中，分布式事务始终是绕不开的复杂命题。作为长期观察此类技术演进的编辑，我深知每一次关于CAP理论的权衡、每一套最终一致性方案的设计、每一层高可用保障的搭建，背后都是无数工程师在可用性与数据一致性之间的精妙博弈。以下从技术视角展开一份详尽分析，以揭示其内在逻辑与演进脉络。
分布式事务的起源，本质是对单体数据库事务的突破。在传统支付系统中，单库的单机事务依赖ACID特性，通过本地锁与两阶段提交保证资金流转的原子性。随着支付场景向高并发、多服务化演进，单库瓶颈显现：用户规模增长、跨服务调用增多，使得单点数据库无法承载数万笔每秒的支付请求。分布式事务应运而生，试图在多个独立节点间维持事务状态，但首当其冲的便是CAP定理的烙印——在一致性、可用性与分区容忍性之间，支付系统往往必须做出痛苦抉择。
CAP权衡在支付场景下尤为显著。理想状态下，系统希望同时满足强一致性和高可用，但网络分区是分布式系统的常态。当服务间通信中断时，系统必须选择：要么牺牲可用性，拒绝写入以维持全局一致性；要么允许部分节点继续服务，暂时容忍数据不一致。支付系统对资金安全的敏感性，使得传统方案倾向于偏向一致性与分区容忍性，如两阶段提交（2PC）或三阶段提交（3PC）。但这类方案在高并发下致命缺陷显现：协调者成为单点瓶颈，参与者锁定资源，导致系统可用性陡降。因此，现代支付架构开始转向“最终一致性”范式的探索——放弃瞬时强一致，允许短暂不一致，但保证最终状态收敛，从而释放可用性的活力。
最终一致性方案在支付系统中的实践，以补偿型事务、异步消息与事件驱动模式为代表。补偿型事务，如Saga模式，将长事务拆解为一系列本地短事务，每个步骤都与补偿操作一一对应。当某一子步骤失败时，反向执行补偿动作以回滚已完成的变更。例如，在“扣款-冻结-转账”的支付流程中，若转账失败，补偿操作会将冻结解冻、扣款回退。但这种模式对补偿逻辑的设计要求严苛，稍有不慎便可能导致数据残留或无限重试。更稳健的方案是异步消息队列与本地消息表的结合：服务在本地事务中写入业务数据与消息记录，再通过可靠的消息中间件将变更通知下游。以支付宝的常见支付流程为参考——用户支付后，账户服务先本地扣款，写入“支付成功”的待发送消息；随后消息推送至交易服务，触发订单状态变更。若推送失败，后台定时任务重试直至成功，最终状态通过全局流水表校对验证。这种设计避免了两阶段锁定，却能通过重试与幂等性保证数据最终一致。
高可用保障是分布式事务落地的最后一道防线。支付系统面临的核心风险在于：网络抖动导致消息丢失、服务崩溃导致事务中断、数据不一致无法自动修复。为此，业界形成一套多层次保障体系。第一层是幂等控制：每个服务接口必须支持幂等处理，通过全局唯一事务ID标记每次请求。这使得重复调用不会产生重复扣款或重复通知。第二层是状态机与重试机制：支付流程定义为清晰的状态机（初始、处理中、成功、失败、补偿中），每个状态变更都有重试次数与超时阈值，超时后触发自动补偿或人工介入。第三层是日志化与审计：分布式事务的每一步操作都被持久化到事务日志数据库，形成完整“痕迹链”。一旦产生数据差异，可通过定时对账脚本比对流水与余额，发现差异后自动发起补偿任务。例如大型支付系统的“夜间对账”机制，在低峰期对全天交易进行逐笔校验，修复所有不一致记录。高可用还需依赖监控与自动恢复：告警系统实时检测事务失败率、队列堆积深度、补偿成功率，触发自动扩容或故障转移。
从演进角度来看，支付系统的分布式事务正从“追求强一致”向“拥抱最终一致+可观测性”转变。早期方案盲目采用两阶段提交，导致系统可用性不足；中期开始引入TCC（try-confirm-cancel）与Saga，但仍存在业务侵入性强的痛点；当前趋势是事件溯源（Event Sourcing）与CDC（Change Data Capture）的结合——利用数据库日志捕获数据变更，通过事件流驱动下游服务状态同步。以部分新兴支付平台为例，它们用Kafka绑定Debezium监听Binlog，实时捕获账户余额表的增量变化，经过幂等处理后推送至交易服务、风控服务，整体事务状态由中央协调器监控并维护。这种方案去掉了传统分布式事务框架的耦合，却使得数据一致性的保障更加依赖于消息可靠性，也对基础设施容错能力提出更高要求。
根本性难题仍未完全解决：当资金安全与高可用冲突时，最终一致性方案中的“最终”可能被不可知网络延迟无限拉长。为此，支付系统行业达成共识：分布式事务不能单纯依赖技术手段，必须与业务闭环、人工审核结合。例如，用户支付失败时，不立即返回失败提示，而是将支付单置为“处理中”，后台通过异步重试或替代通道完成，最终通过短信或APP通知用户结果。这种“柔性事务”本质是用业务层面的可接受延迟，换取技术架构的可用性提升。
综上，分布式事务在支付系统中的演进，本质上是对CAP权衡的逐步接受与精细化管控：从补偿型方案到事件驱动架构，再到结合可观测性的最终一致性，每一次进步都是以牺牲部分强一致为代价，换取可用性的显著提升。当前的成熟架构已能够支撑微信、支付宝等系统日均数十亿笔交易，但其背后是幂等设计、重试机制、对账系统与人工兜底形成的组合拳。未来，随着确定性投递协议与分布式账本技术的发展，最终一致性可能向“可预测的最终一致”演进——支付系统既保有高可用，又能在毫秒级精度内保证数据收敛，而这正是行业孜孜以求的圣杯。
保证分布式系统数据一致性的6种方案
编者按 ：本文由「高可用架构后花园」群讨论整理而成。
有人的地方，就有江湖
有江湖的地方，就有纷争
在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？
具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。
A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。
在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。
为了便于讨论问题，先简单介绍下数据一致性的基础理论。
强一致
弱一致性
最终一致性
在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。
但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，群友的讨论分成以下 6 种解决方案。
业务整合方案主要采用将接口整合到本地执行的方法。
拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。
优点： 解决（规避）了分布式事务。
缺点： 显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。
由于这个方法存在明显缺点，通常不建议使用。
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。
消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。
人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
消息日志方案的核心是保证服务接口的幂等性。
考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。
eBay 方式的主要思路如下。
Base：一种 Acid 的替代方案
此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。
文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。
如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通过 支持局部故障 而不是系统全局故障来实现的。
下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。
这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。
文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。
这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。
文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息 放在一个本地事务 来完成。
同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性， 增加一个更新记录表 updates_applied来记录已经处理过的消息。
系统的执行伪代码如下
（点击可全屏缩放图片）
基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。
在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。
通过以上方法，达到了分布式系统的最终一致性。
进一步了解 eBay 的方案可以参考文末链接。
随着业务规模不断地扩大，电商网站一般都要面临拆分之路。
就是将原来一个单体应用拆分成多个不同职责的子系统。
比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。
拆分首先要面临的是什么呢？
最开始的单体应用所有功能都在一起，存储也在一起。
比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。
因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。
但拆分之后就不同了，不同的子系统都有自己的存储。
比如订单中心就只管理自己的订单库，而库存管理也有自己的库。
那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。
这就涉及一个『 分布式事务 』的问题。
分布式事务有两种解决方式
1. 优先使用异步消息。
上文已经说过，使用异步消息 Consumer 端需要实现幂等。
幂等有两种方式， 一种方式是业务逻辑保证幂等 。
比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。
另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现 。
对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。
发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。
2. 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。
这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。
比如 A 同步调用 B，C。
A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。
如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。
则由一个中心服务对比三方的事务记录表，做一个最终决定。
假设现在三方的事务记录是 A 成功，B 失败，C 成功。
那么最终决定有两种方式，根据具体场景：
对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。
那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？
实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。
总结起来，其实两种方式的根本原理是类似的，也就是 将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性 。
交易创建的一般性流程
我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。
把各个功能点按照一定流程串起来，就完成了交易创建的过程。
面临的问题
每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？
方案选型
服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。
试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。
所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。
消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。
前者问题可以通过重试解决；后者可以选用事务消息来保证。
所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。
在交易创建过程中，锁券和扣减库存是这样的两个典型场景。
要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。
但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。
我们在交易创建流程中， 首先创建一个不可见订单 ，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。
如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。
业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。
主要思路如下，大部分信息引用自官方网站。
分布式事务服务简介
分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。
DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。
核心特性
传统关系型数据库的事务模型必须遵守 ACID 原则。
在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。
在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。
这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。
基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。
DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。
简单的说，DTS 框架有如下特性：
以下是分布式事务框架的流程图
实现
与 2PC 协议比较
1. 电商业务
公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。
对于业务部门来说，电商部门的订单支付，需要调用
从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。
我们采用的方式是同步调用，首先处理本地事务业务。
考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。
具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。
(点击图片可以全屏缩放)
2. 用户信息变更
分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。
In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.
英文版 ：
中文版：
感谢李玉福、余昭辉、蘑菇街七公提供方案，其他多位群成员对本文内容亦有贡献。
大白话讲解“什么是CAP定理？”
大白话讲解“什么是CAP定理？”
CAP定理是分布式系统领域的一个重要定理，它告诉我们一个分布式系统在设计时，最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项特性中的两项。
一、CAP各是什么含义？
二、CAP定理的核心内容
CAP定理告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容错性这三项特性。
换句话说，你只能选择其中的两项来实现。
三、CAP定理的实际应用
在实际应用中，我们需要根据业务的需求来权衡这三项特性。
四、常见的分布式系统权衡
五、总结
CAP定理是分布式系统设计时的一个重要指导原则。
它告诉我们，在设计分布式系统时，需要根据业务的需求来权衡一致性、可用性和分区容错性这三项特性。
通过合理的权衡和选择，我们可以设计出既满足业务需求又具有高可用性和容错性的分布式系统。
以上就是对CAP定理的大白话讲解，希望能帮助你更好地理解这个重要的分布式系统定理。
系统架构设计面试指南(01)-微服务和CAP
系统架构设计面试中关于微服务和CAP定理的核心要点包括微服务的定义与优势、CAP定理的内容与权衡策略，以及两者在分布式系统设计中的综合应用。 以下从微服务架构和CAP定理两个核心模块展开详细说明：
一、微服务架构
1. 定义与核心特征微服务是一种通过松散耦合的服务构建应用程序的架构风格，其核心特征包括：
2. 优势与适用场景
3. 挑战与解决方案
二、CAP定理
1. 定理内容CAP定理指出，分布式系统在分区（网络故障导致节点间通信中断）情况下，只能同时满足以下两个属性：
2. 权衡策略
3. 实际应用中的扩展
三、面试常见问题与回答策略
1. 微服务相关问题
2. CAP相关问题
四、综合应用建议
通过系统掌握微服务的拆分原则、通信机制和CAP定理的权衡逻辑，结合实际业务场景设计架构方案，可在面试中展现对分布式系统设计的深度理解。
暂无评论内容