3. 支付系统架构设计高频问题

支付系统架构题是面试中最容易“答得热闹、得分不高”的一类。候选人往往一上来就讲缓存、消息队列、分库分表，却忽略了面试官真正想确认的是：你是否理解资金安全优先于吞吐、一致性优先于性能、可回滚优先于炫技。本章给出一套可复用的回答框架，并用追问路径帮你把答案从“背概念”升级为“有工程判断”。

一、核心原理：支付架构的四个不可妥协

面试官问“怎么设计高并发支付”，本质是在问优先级。支付系统的第一性原理是资金不丢、不重、不错、可追溯。因此回答时要先亮出底线：

• 幂等是资金安全的地基：同一笔请求无论重试多少次，结果必须一致。常用唯一业务单号 + 数据库唯一索引 + 状态机前置校验。
• 分布式事务不是必须强一致：支付核心链路多用 TCC、Saga 或本地消息表，追求最终一致，而不是全局锁。
• 高可用靠冗余与隔离：多机房、多副本、熔断降级、故障隔离，而不是单点堆机器。
• 容灾靠演练：没有演练的容灾方案等于没有方案，RTO/RPO 必须可量化。

二、方法流程：五步回答法

1. 澄清场景：是收单、退款、清结算还是账户充值？并发量级、峰值 TPS、是否跨机房。
2. 定义一致性目标：哪些环节必须强一致，哪些可以最终一致。
3. 设计幂等与状态机：给出唯一键、状态流转、重复请求处理策略。
4. 设计高可用与容灾：多活、降级、限流、熔断、故障切换。
5. 给出兜底与验证：对账、补偿、压测、混沌演练、监控告警。

三、案例/场景：一笔支付请求的完整链路

以“用户下单支付 100 元”为例，面试中可按如下结构展开：

1. 网关层：限流、鉴权、防重放（requestId + 时间戳 + 签名）
2. 支付核心：创建支付单，写入唯一索引（merchantId + orderNo）
3. 状态机：INIT -> PROCESSING -> SUCCESS / FAIL
4. 调用渠道：超时后不直接失败，进入“未知态”，由查询补偿
5. 账务层：记账、冻结、扣减，使用本地消息表保证最终一致
6. 对账层：T+1 与渠道对账，差异自动挂起并人工介入

关键点在于：超时不是失败。支付系统必须区分“明确失败”和“未知态”，未知态只能通过查询或对账解决，不能直接退款或重试扣款。

四、高频追问与公司侧重点

五、误区与复盘

• 误区一：一上来就讲分库分表。支付核心瓶颈往往在渠道调用和账务一致性，不是数据库。
• 误区二：把幂等等同于去重。幂等还要保证状态一致和结果可查询。
• 误区三：忽略未知态。超时、网络抖动、渠道无响应都必须有补偿路径。
• 误区四：容灾只讲架构不讲演练。没有切换演练和 RTO/RPO 指标，方案不可信。