分布式事务：本地事务 + RPC 的“隐形炸弹”
只要系统被拆成多个微服务，“分布式事务”就绕不过去。
很多同学只记住了@Transactional，却忽略了一个关键事实：
它只对本地数据库负责，对远端 RPC 一无所知。
真正的坑，往往就埋在“本地事务里嵌套 RPC 调用”这一行代码里。
一、问题场景：A 调 B，要保证状态一致
典型面试题：
- 系统 A、系统 B，通过 RPC 相互调用。
- 有个业务要求：两边的状态必须一致。
- A 中有一个方法加了
@Transactional：- 先通过 RPC 调 B，B 把状态更新为“生效中”。
- 根据 B 的返回结果，A 更新自己的本地数据为“生效中”。
问：可能出现什么问题？
二、几个常见的坑
1. 长时间 RPC 拖垮数据库
- A 在开启本地事务后，发起一个执行时间很长的 RPC。
- 事务期间，数据库连接一直被占用；
- 高并发时，很容易把连接池拖到见底，引发雪崩。
2. B 成功，A 回滚：两边状态不一致
- B 更新成功，状态“生效中”。
- A 在本地更新时抛异常，事务回滚，A 依然是旧状态。
- 最终：B 生效，A 未生效，数据不一致。
3. B 实际成功，但 A 认为失败
- 网络抖动导致 RPC 超时：
- B 实际已经成功处理；
- A 认为调用失败，可能回滚本地事务；
- 两边状态再次不一致。
4. 超时后的“不确定性”
- 超时发生时，A 无法判断 B 是否执行成功。
- 单靠本地事务，根本无法解决这种“不确定结果”的问题。
三、本质：@Transactional 只管本地，不管远端
这一类问题的本质：
@Transactional只对本地数据库负责：- 能确保 A 自己的多条 SQL 是原子性的；
- 无法保证包含 RPC 在内的整个调用链是一致的。
想拿 @Transactional 去覆盖远端服务，是思维上的错位。
四、主流解法一：本地消息表（最终一致）
1. 思路
-
把“本地更新”和“对外发送一条消息”放在同一个本地事务中。
-
事务提交成功后，代表：
- A 的本地状态已更新；
- 要通知 B 的“消息”已经可靠地写入消息表。
-
后台有一个异步任务：
- 从本地消息表里捞出未发送或发送失败的记录；
- 不停重试调用 B 的接口，直到成功或超过重试上限。
2. 特点
- 获得的是最终一致性，而不是强一致。
- 避免了本地事务直接包含长时间 RPC。
- 实现简单，常用在中小规模系统中。
五、主流解法二：MQ 事务消息（交给消息中间件协调）
1. 思路
如果系统中已经有 MQ（如 RocketMQ）：
- A 首先发送一条“半消息”到 MQ；
- 然后在本地开启事务，更新自己的数据库；
- 本地事务成功后，告知 MQ 提交这条消息为“正式消息”；
- B 订阅消费这条消息，更新自己的状态。
如果 MQ 一段时间内没收到“提交/回滚”的反馈，它会：
- 反查 A 的本地事务状态；
- 决定是提交还是丢弃这条消息。
2. 特点
- 把“事务协调”的复杂度交给 MQ。
- 适合对可靠性要求很高、链路较长的分布式系统。
六、主流解法三：同步调用 + 业务补偿（TCC 思路）
1. 思路
- 执行主业务时，同时设计一条对应的补偿路径（rollback）。
- 当任何一个环节失败时，通过调用远端的补偿接口，把状态拉回去。
- 不刻意追求“瞬时强一致”，而是通过补偿达到“最终一致”。
2. 特点
- 非常考验业务建模能力：
- 要为每种变更设计清晰的“撤销逻辑”。
- 通常只在关键链路、金额类核心业务中使用。
七、异步任务失败后的兜底
以本地消息表为例，面试官常追问：
如果异步任务也一直失败怎么办？
可按以下层次回答：
- 在消息表中记录重试次数；
- 每次失败次数 +1；
- 超过阈值（如 3 次或 5 次）：
- 标记为“死信”或“失败状态”；
- 触发告警，由运维或业务方人工干预；
- 也可以设计死信队列，专门承接多次失败的消息。
八、没有银弹，只有权衡
@Transactional解决的是单服务内一致性。- 分布式场景更多要接受：最终一致性 + 补偿机制。
- 选型要在：
- 实现复杂度
- 链路时延
- 一致性要求
之间做平衡。
九、面试思路
-
先说明问题本质：
- 本地事务 + RPC 是不可靠的，
@Transactional不等于分布式事务。
- 本地事务 + RPC 是不可靠的，
-
再给出主流方案：
- 本地消息表 → 最常见且易实现；
- MQ 事务消息 → 更规范但对基础设施依赖更高。
-
然后提到补偿思路：
- 对强依赖同步链路，可以设计补偿接口落地 TCC。
-
最后回答面试官追问：
- 本地消息表的重试机制、死信队列、人工介入策略。
扫一扫
510
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
