刚性事务与柔性事务

一句话结论

• 刚性事务，遵循 ACID 原则，具有强一致性。比如，数据库事务。

• 柔性事务是根据不同的业务场景使用不同的方法实现最终一致性。即我们可以根据业务的特性做部分取舍，容忍一定时间内的数据不一致。

总结来讲，与刚性事务不同，柔性事务允许一定时间内，数据不一致，但要求最终一致。而柔性事务的最终一致性，遵循的是 BASE 理论。

一、本质：同一问题在 CAP 里的两条取舍路线

分布式事务的方案空间，本质上是在 CAP 里选边（理论背景见 分布式理论-CAP原则）：

• 刚性事务选 C（强一致）：宁可牺牲可用性与性能，也要任何时刻读到的数据一致；
• 柔性事务选 A（可用）+ 分区容忍：接受短暂不一致，换取高并发下系统不锁死，靠补偿收敛到一致。

把 ACID 与 BASE 逐条对上，能看清"柔性"到底柔掉了什么：

ACID（刚性）	含义	BASE（柔性）	对应取舍
Atomicity 原子性	全成或全败，无中间态	Soft state 软状态	允许存在中间状态
Consistency 一致性	事务前后约束不破坏	Eventually consistent 最终一致	中间态经过补偿/重试后收敛
Isolation 隔离性	并发事务互相不可见	（基本放弃）	中间态对外可见，需业务容忍或屏蔽
Durability 持久性	提交即永久生效	同样要求	两者共同的底线，不取舍

二、分界线：资源锁定与中间态

维度	刚性事务	柔性事务
一致性	强一致	最终一致
资源占用	两阶段间锁定资源、同步阻塞	一阶段即提交本地事务，不长期锁资源
中间态	对外不可见（靠隔离性保证）	对外可见，需业务能容忍/屏蔽
性能	低（量级差距）	高
复杂度落点	在数据库/中间件层，应用近乎零改造	转移到业务层：补偿、幂等、对账都要自己写
典型故障形态	阻塞、协调者单点、锁等待	空回滚、悬挂、消息丢失、补偿失败

强一致 ◄──────────────────────────────────────► 最终一致
 2PC/XA    3PC     TCC    事务消息/本地消息表    Saga    最大努力通知
 |◄────── 刚性 ──────►| |◄──────────────── 柔性 ────────────────►|

三、典型方案归类

• 刚性：2PC/XA、3PC。数据库/中间件层实现，应用透明。其中 3PC 是理论改进，工程上很少直接落地。
• 柔性：TCC、本地消息表、事务消息（RocketMQ）、Saga、最大努力通知。业务层实现，每种都有自己的补偿与幂等套路。

各方案的完整流程、优缺点与面试话术统一拆在同目录总纲 分布式事务解决方案 里。本篇不重复，只给一张归类速查：

方案	阵营	一句话特征
2PC/XA	刚	prepare 阶段锁资源，等协调者发令，强一致低性能
3PC	刚	加一轮询问+超时机制，缓解阻塞但仍有不一致窗口
TCC	柔	Try 预留资源、Confirm/Cancel 收尾，准强一致，业务侵入最大
本地消息表	柔	业务与消息同库同事务绑定，扫表重投兜底
事务消息	柔	half 消息 + 回查机制，去消息表，国内主流
Saga	柔	长事务拆本地事务链，失败反向补偿，无隔离性
最大努力通知	柔	衰减重试 N 次 + 对账兜底，一致性最弱

四、选型表

判断条件	结论
强一致是硬要求 + 并发低 + 单应用跨多库	XA/2PC
资金/交易核心 + 高并发	TCC
一般异步场景（下单后扣库存、发券）	事务消息 / 本地消息表
流程长、参与方多、含第三方或遗留系统	Saga
纯通知类，丢了可对账补	最大努力通知
并发高的互联网业务（默认姿态）	柔性事务，不用 XA

五、速记

• 刚性靠锁，柔性靠补：一个用资源锁定换一致，一个用补偿换吞吐。
• 刚性的复杂度在中间件，柔性的复杂度在业务（Try/Confirm/Cancel、补偿服务、幂等键）。
• 柔性三件套标配：幂等、重试、对账，缺一个都会在故障时翻车。
• 允许不一致 ≠ 一直不一致：中间态的暴露时长要可控，且业务上有屏蔽手段（如"处理中"状态）。

延伸阅读：分布式事务解决方案（方案总纲）、分布式理论-CAP原则、分布式理论-BASE、什么是分布式事务？、全局事务与分支事务、分布式理论-2PC。

2026-10 扩充（原内容过薄）。