本文基于《金融支付架构实战指南：技术、安全与合规》核心内容整理，聚焦支付场景下分布式数据一致性，从理论、协议、工程实践到选型建议，一站式吃透支付系统一致性难题。
一、开篇：支付为什么最怕 “数据不一致”？
支付系统 =支付架构（请求 / 流转） + 账务架构（记账 / 核算），两者必须强协同。一旦出现：
- 用户扣款成功 → 商户未入账
- 订单已支付 → 库存未扣减
- 主库宕机 → 从库数据缺失
直接导致资金损失、资损风险、对账失败、合规问题。
分布式系统天生三态：成功 / 失败 / 超时（未知），这是一致性灾难的根源。
二、分布式系统三大核心难题（支付必看）
分布式 = 单机问题 + 网络协作问题，核心要解决三件事：
表格
| 问题 | 核心诉求 | 支付影响 |
|---|---|---|
| 计算 | 原子性、隔离性 | 交易不被打断、不互相污染 |
| 存储 | 一致性、持久性 | 资金流水绝对准确、不丢不重 |
| 网络 | 确定性、安全性 | 延迟、乱序、丢包、节点宕机容错 |
结论：支付必须优先保证存储一致性，计算与网络做容错与安全兜底。
三、从单机到多机：一致性演进路线
下面在书籍中有具体的案例讲解，这里列举摘要。
1. 单机一致性（基础盘）
- CPU-Cache-Memory：用
volatile保证可见性、单操作原子性。 - Memory-Disk：先内存后磁盘 + 状态标记，牺牲并发换强一致。
- Memory-Log-Disk：WAL 预写日志，顺序写日志 + 异步刷盘，参照MySQL 核心机制。
2. 双机一致性（主从）
支付必须用：MySQL 5.7+ AFTER_SYNC流程：
- 主机发 binlog 到从库
- 从库 ACK 确认收到
- 主机再提交、响应客户端
避免：主库已提交、从库未同步 → 主库宕机 →资损。
3. 多机一致性（共识）
真正分布式 =共识算法，不只同步，还要：
- 自动选主
- 版本裁决
- 故障自愈
Raft 是支付存储标配：
- Leader 写入、Follower 同步
- 多 Raft 组拆分分片，突破性能瓶颈
- PolarDB-X、TiKV 均基于此架构
四、一致性级别：支付该选哪一种？
| 级别 | 定义 | 支付是否用 |
|---|---|---|
| 强一致性 | 任何时刻所有节点读到最新值 | ✅ 核心资金、账户、流水 |
| 单调一致性 | 只保证自己不读旧 | ⭕ 辅助查询 |
| 会话一致性 | 单次会话不读旧 | ⭕ 前端展示 |
| 最终一致性 | 最终一致，延迟不确定 | ✅ 非核心、可补偿 |
| 弱一致性 | 完全不保证 | ❌ 支付禁用 |
支付铁律：核心链路强一致（CP），非核心最终一致（AP）。
五、分布式事务：支付一致性的终极武器
分布式事务 = 跨库 / 跨服务的原子提交 / 回滚。
支付场景高频：订单 + 账户 + 库存 + 积分 → 必须一起成功 / 失败。
1. 2PC（两阶段提交）—— 强一致标准方案
阶段 1：Prepare（准备）所有库锁定资源、执行但不提交。阶段 2：Commit/Rollback（提交 / 回滚）全部成功则提交，任一失败则回滚。
XA 协议：DTP 模型三角色
- AP：应用
- TM：事务管理器
- RM：资源管理器（数据库）
适用：低并发、强一致、关系型数据库场景。缺点：阻塞长、性能差、协调者单点风险。
2. 3PC（三阶段提交）—— 别用！
CanCommit → PreCommit → DoCommit看似优化了锁时间，实则自动提交会导致数据不一致，支付场景直接弃用。
3. Seata AT —— 无侵入、工程友好
改进 2PC：第一阶段直接提交，用全局锁解决：
- 脏读：
select for update+ 全局锁 - 脏写：TC 协调全局锁
适合：中小并发、对业务代码无侵入的后台业务信息管理系统，不用于支付场景。
4. TCC —— 高并发支付首选（业务级事务）
Try → Confirm → Cancel
- Try：资源预留（冻结金额 / 冻结库存）
- Confirm：确认执行
- Cancel：取消释放
核心优势：不锁数据库、高并发、业务可控。
支付必备：组合支付、账户扣款、券 + 余额混合支付。
必须处理三问题：空回滚、悬挂、幂等。
5. SAGA —— 长事务、低风险用
适合：流程长、可补偿、非资金核心。支付不推荐：隔离性差、脏读难治理。
6. 本地消息表 / 事务消息 —— 最终一致神器
适合：A 成功 → B 必须成功（订单→支付→物流）
- 本地事务：业务入库 + 消息入库
- 异步投递 + 重试 + 幂等
- RocketMQ 事务消息替代本地消息表
支付高频：扣款成功 → 通知订单 / 积分 / 物流。
六、6 种分布式事务终极对比（直接收藏）
| 方案 | 资源 | 一致性 | 性能 | 业务侵入 | 支付推荐度 |
|---|---|---|---|---|---|
| XA/2PC | 锁定 | 强一致 | 低 | 无 | ⭐⭐⭐ |
| Seata AT | 提交 | 最终一致 | 中 | 无 | ⭐⭐⭐⭐ |
| TCC | 预留 | 强一致 | 高 | 高 | ⭐⭐⭐⭐⭐ |
| SAGA | 提交 | 最终一致 | 高 | 极高 | ⭐ |
| 本地消息表 | 提交 | 最终一致 | 高 | 中 | ⭐⭐⭐⭐ |
| 事务消息 | 提交 | 最终一致 | 高 | 中 | ⭐⭐⭐⭐⭐ |
七、分布式数据库：支付海量交易的终极解法
单表瓶颈 → 分库分表 → 复杂度爆炸 →分布式数据库登场。
核心特性（支付必看）：
- 数据容灾：3 副本 / 5 副本、跨城多活
- 透明分布式：像单机一样使用
- 强一致分布式事务：无需业务改造
- 自动分片：哈希 / 范围 / 列表
- 全局索引 + 二级分区
分片四原则：
- 均匀：避免数据倾斜
- 查询就近：高频查询同分片
- 避热点：不按频繁更新字段分片
- 业务亲和：同用户 / 同商户放同分片
支付最佳实践：CO_HASH 尾号分片，让同一用户订单 / 账单 / 支付单同节点，本地事务代替分布式事务，性能暴涨。
八、支付系统一致性落地总纲领
核心资金强一致（CP）
- MySQL：AFTER_SYNC
- 分布式库：PolarDB-X、TiKV
- 事务：XA / TCC
非核心最终一致（AP）
- 事务消息 / 本地消息表
- 可重试、可补偿、幂等
架构铁律
- 能本地事务 → 不用分布式事务
- 可以最终一致 → 不强一致
- 必须强一致 → 用 TCC 或 XA
- 高并发支付 → 首选 TCC
工程兜底
- 全链路幂等
- 定时对账
- 异步补偿
- 监控告警（超时、不一致、重试失败）
九、总结
支付系统的一致性，本质是在分布式不确定性下，守住资金安全底线。从单机日志 → 主从同步 → 共识算法 → 分布式事务 → 分布式数据库，层层递进、层层保障。
一句话记住：核心强一致、非核心最终一致；高并发用 TCC，低并发用 XA/Seata，异步流程用事务消息。
