分布式场景下MySQL需用最终一致性替代强一致性：①本地消息表模式在事务中写业务+消息，轮询投递并幂等处理；②Seata AT模式通过undo_log自动补偿，侵入小但需注意长事务锁风险；③最大努力通知+对账兜底适用于低一致性要求场景；④优先业务建模降级，收敛强一致到单库或采用TCC模式。
在分布式场景下，MySQL 单机事务（ACID）无法直接跨库、跨服务保证一致性，必须借助外部机制或架构设计来扩展事务语义。核心思路是：用“最终一致性”替代强一致性，通过补偿、记录、协同等手段降低数据不一致风险。
基于本地消息表的可靠事件模式
适用于服务间异步协作，比如订单创建后扣减库存。关键是在同一 MySQL 事务中，把业务操作和“待发送消息”写入本地消息表，再由独立线程轮询并投递到消息队列（如 RocketMQ/Kafka）。下游消费成功后，上游更新消息状态为已处理。
- 消息表需包含唯一业务 ID、消息内容、状态（待发送/已发送/已确认）、重试次数、创建时间
- 投递服务需幂等：根据业务 ID 去重，避免重复消费导致重复扣减
- 配合定时任务扫描超时未确认的消息，触发补偿或告警
Seata 的 AT 模式（自动补偿型分布式事务）
Seata 是主流开源方案，AT 模式对业务代码侵入小。它在每个 MySQL 分支事务执行前后，自动记录 undo_log（反向 SQL），全局事务协调器（TC）统一管理提交或回滚。若某分支失败，TC 驱动各参与者回滚本地 undo_log。
- 需在 MySQL 库中建 undo_log 表，并开启 binlog（用于解析 SQL 影响行）
- 应用接入 Seata 仅需加 @GlobalTransactional 注解，无需手动写补偿逻辑
- 注意长事务风险：全局锁持有时间过长可能阻塞其他事务，建议拆分大事务
最大努力通知 + 对账兜底
对一致性要求不高但需可追溯的场景（如积分发放、优惠券推送），采用“先执行、再通知、多次重试、定期对账”的策略。每次通知带版本号或时间戳，下游按幂等规则处理；后台每日跑批比对核心表与日志表，发现差异自动修复或人工介入。
- 通知日志表要记录目标服务、请求参数、响应结果、耗时、重试次数
- 重试间隔建议指数退避（如 1s → 3s → 9s → 27s）
- 对账脚本应支持按日期范围、业务类型、状态筛选，输出明细供核查
避免过度依赖分布式事务
很多场景可通过业务建模降级解决。例如“支付+发货”不强绑，改为“支付成功→生成待发货单→人工/自动调度发货”，用状态机驱动流程，异常时卡在中间态，人工干预成本远低于技术兜底。
- 优先识别哪些环节允许短暂不一致（如用户余额显示延迟 2 秒）
- 将强一致逻辑收敛到单库单表（如所有账户操作走 account_db），用 MySQL 原生事务保障
- 用 TCC 模式（Try-Confirm-Cancel）替代跨库 update，把事务控制权交给业务层，更灵活也更可控
