📚 课程目录第3章面试评分表与模拟面试清单

第3章：支付核心链路与一致性保障

  章节导入：支付系统技术专家的核心能力之一是设计高可用、强一致的支付链路。本章聚焦“支付下单→扣款→异步通知→账务记账”全链路中，面试官最关注的技术选型、分布式事务方案、异常处理策略与性能平衡。

考察点	链路整体认知、分布式事务方案选型、异常处理意识、幂等设计
回答框架	① 拆链路：请求→预扣库存→生成订单→扣款→异步通知→记账；② 关键点：对账与补偿；③ 选型：采用TCC（Try-Confirm-Cancel）模式，用Seata管理全局事务；④ 幂等：订单号做数据库唯一键、回调去重表。
示例回答	“用户下单后先Try预扣库存，订单状态置为‘处理中’；支付网关返回后Confirm更新订单、真实扣款；若超时则Cancel回滚。中间状态通过定时任务扫描补偿表做最终一致，支付回调接口使用订单号+事务ID做幂等。” （约80字）
可能追问	TCC与Saga的适用场景？如何避免悬挂事务？预扣库存过期怎么处理？
避坑提醒	不要只讲理论，要结合具体中间件（如Redis预扣、MQ异步通知）。避免说“完全强一致”，支付场景通常接受最终一致性。

考察点	幂等设计、回调重试机制、消息可靠性、对账兜底
回答框架	① 接收方接口设计幂等（唯一键+状态机）；② 重复通知：根据payment_no查询已有状态，已终态直接返回成功；③ 丢失：依赖支付平台定时轮询 + 商户主动查询接口；④ 兜底：T+1对账文件核对差异。
示例回答	“我们在收款回调入口用payment_no+type做数据库唯一索引，首次插入成功，重复插入返回主键冲突则忽略。若回调丢失，定时任务每隔1分钟拉取未终态订单主动调用支付查询接口补单，并使用消息队列异步补偿。” （约90字）
可能追问	唯一索引和业务主键冲突怎么区分？MQ消息丢失如何保证？
避坑提醒	不要只依赖MQ的可靠性，一定要加上本地补偿表。幂等处理要提前考虑并发写冲突。

考察点	复式记账原理、流水设计、分布式事务边界、对账机制
回答框架	① 采用借贷复式记账，每笔交易生成借、贷两条流水（balance_log）；② 使用分布式事务+本地消息表确保写账流水与业务状态一致；③ 账务与支付模块通过事务消息解耦；④ 日终运行试算平衡脚本，校验账户余额=流水汇总。
示例回答	“每笔支付成功后，账务系统接收Seata全局事务消息，写入借记流水和贷记流水，事务ID作为幂等键。日终对账扫描所有balance_log，若某笔只写了一条则触发补偿。账户余额通过快照表+流水增量更新，定期做全量校验。” （约85字）
可能追问	如何处理账务流水与订单状态不一致？出现过挂账怎么排查？
避坑提醒	不要只讲“用事务”，要具体到表结构设计（如流水号规则、余额快照策略）。避免说“无差错”，实际业务需接受对账发现后补数据。

💡 面试加分技巧：在回答中主动引出“补偿机制+对账”双保险，以及对“最终一致性”与“强一致性”的取舍判断（比如支付网关侧用强一致，内部记账允许秒级最终一致）。

项目名称	支付平台链路升级与分布式一致性改造
业务背景	原有单体支付系统扣款与记账耦合，下游频繁超时导致订单状态不一。需要升级为独立支付网关+账务系统，支持百万级日订单。
规模指标	日均订单 120 万笔，峰值 2000 TPS，对账差异率 ≤0.001%
技术栈	Spring Boot + Seata（AT模式） + Redis + RocketMQ + MySQL（分库分表） + XXL-Job
核心难点	① 分布式事务长链路性能：Seata AT模式下锁冲突严重，改为TCC+本地消息表；② 重复回调与丢单：设计幂等表+主动查单补偿；③ 账务一致性：引入balance_journal流水表，日终试算平衡。
面试高频追问	Seata AT与TCC如何选择？分库后全局事务怎么处理？库存扣减与支付回滚不一致怎么解决？
可迁移话术	“在支付链路中我们采用TCC模式，通过本地补偿表和定时任务实现最终一致性。关键在于合理划定事务边界——支付网关内部使用乐观锁+短事务，账务写入使用MQ异步削峰，日终对账兜底。” （约80字）

⚠️ 常见误区：回答时罗列太多技术名词（如“我们用Seata+RAbbitMQ+Redis”），但不说为什么选型。面试官更想知道你的选型依据和权衡过程。另外，不要忽略“业务补偿”和“人工介入”场景，这是支付系统的现实。