数据库操作和RPC调用不可共处同一本地事务边界，因本地事务无法控制远程服务状态，易致数据不一致；应先提交本地事务，再异步触发RPC，并通过幂等设计、任务表重试与补偿机制保障最终一致性。
数据库操作和 RPC 调用不能共处一个本地事务边界——这是 Java 事务管理中最常被误用、也最容易引发数据不一致的硬约束。
为什么 RPC 不能放进 @Transactional 里
本地事务（如 Spring 的 @Transactional）只对当前数据源（比如 PostgreSQL 或 MySQL）生效，它无法控制远程服务的执行状态。一旦 RPC 调用成功但本地事务随后回滚，或本地已提交而 RPC 失败，就会出现“半成功”状态：
- 本地写入成功，RPC 实际也执行了（如扣库存、发通知），但因网络超时被判定失败 → 本地回滚，远端却不可逆
- 本地写入成功并提交，RPC 因重试机制未触发或用户放弃重试 → 远端始终没执行，业务逻辑断裂
- 事务长时间持有连接和行锁，而 RPC 等待耗时不可控（如生成报告、调第三方风控）→ 数据库连接池打满、并发下降
推荐的分层处理方式
把“写本地”和“调远程”在逻辑与时间上解耦，用明确的责任划分替代强一致性幻想：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 先完成本地事务：用 @Transactional 保证数据库操作原子性，完成后立即提交
- 再触发 RPC：在事务提交后的回调中发起调用，例如通过 TransactionSynchronizationManager.registerSynchronization()
- 失败必须可补偿：RPC 调用失败时，记录失败日志 + 写入本地任务表，由定时任务或消息队列驱动重试（最大努力交付）
- 所有 RPC 接口需幂等：要求服务提供方支持重复请求识别（如传入唯一业务 ID、时间戳+签名），避免重试导致重复扣款、重复发券等问题
典型落地结构示例
以订单支付成功后通知积分服务为例：
立即学习“Java免费学习笔记（深入）”；
- 第一步：更新订单状态为“已支付”，插入积分变动明细（事务内完成）
- 第二步：事务提交后，注册同步回调，异步调用积分服务的
addPoints(orderId, amount) - 第三步：若 RPC 超时或返回失败，将该请求持久化到
rpc_retry_task表，含重试次数、下次执行时间、原始参数 - 第四步：后台 Job 每 30 秒扫描待重试任务，最多重试 3 次；第 3 次失败则告警人工介入
需要避开的陷阱
这些看似合理实则危险的做法要主动规避：
- 在同一个 @Transactional 方法里既写 DB 又调 FeignClient/Dubbo —— 即使加了 rollbackFor 也无法挽回远端副作用
- 用 try-catch 吞掉 RPC 异常后“假装成功” —— 掩盖问题，导致下游数据永远缺失
- 把 RPC 放进事务方法里但依赖“最终一致”来安慰自己 —— 缺少补偿机制的“最终一致”只是“可能永远不一致”
- 让 RPC 调用阻塞主线程等待结果再决定是否提交事务 —— 彻底违背事务最小化原则，性能与可靠性双崩
