📚 课程目录第3章支付系统核心架构与故障分类

3. 支付系统核心架构与故障分类：系统分层、故障类型、典型场景

支付系统通常采用分层架构来隔离职责、提升容错能力。各层独立演化，同时引入新的故障传播路径。面试考察你对整体架构的认知深度，以及面对故障时的归类、定位、隔离能力。以下是核心分层与典型故障的对应关系。

💡 记忆口诀：接入防超限，交易幂等先，账务需对平 —— 三层各有典型故障，面试时要能按层举例。

考察点	架构认知深度、故障分类归纳能力、分层隔离意识
回答框架	① 分层概述（接入层→交易层→账务层→清算层） ② 每层核心职能与边界 ③ 每层典型故障（接入层：网络超时/限流；交易层：幂等/重复；账务层：一致性/挂账） ④ 故障传递与隔离策略
示例回答	“支付系统分为四层：接入层处理协议转换和限流，常见故障是网络超时或洪峰导致拒绝服务；交易层保障请求幂等，容易出现重复支付或事务回滚；账务层负责借贷记账，故障多体现为余额不一致或对账差异；清算层处理机构间结算，故障常为文件丢失或延迟。各层通过超时降级、异步对账等方式隔离影响。”
可能追问	① 如何设计接入层的降级策略？ ② 交易层幂等如何实现？ ③ 账务层出现“长款”如何排查？
避坑提醒	❌ 只背分层名称，不举例故障场景 ❌ 混淆“交易层”和“账务层”的职责 ✅ 强调故障隔离：接入层限流保核心，账务层离线对账

考察点	故障归属判断、幂等方案设计、全链路排查思路
回答框架	① 定位：交易层 + 接入层（幂等密钥缺失） ② 根本原因：客户端重试/超时重发+服务端未做去重 ③ 根治方案：接入层生成唯一请求ID，交易层校验状态机 ④ 兜底：对账系统定期发现并冲正
示例回答	“重复支付是交易层典型故障，常由网络超时后客户端重试引起。根治在于接入层生成全局唯一请求ID，交易层利用该ID做仓库锁去重；同时交易状态机需支持‘已支付’状态防重复修改。上线对账脚本每日扫描重复流水并自动冲正，将影响降为零。”
可能追问	① 分布式环境下唯一ID如何生成？ ② 状态机设计要注意什么？ ③ 对账冲正如何保证最终一致性？
避坑提醒	❌ 只谈幂等不考虑资金安全 ❌ 忽略对账兜底 ✅ 强调“接入层+交易层+对账层”三层防御

考察点	账务故障认知、排查方法论、对账能力
回答框架	① 故障类型：账务层一致性故障（不满足借贷恒等式） ② 排查步骤：a. 定位差异发生时间段 b. 比对交易流水与账务流水 c. 检查是否存在未记账的补偿事件 d. 确认批量脚本是否漏跑 ③ 修复：补记/冲正，并引入自动化对账平台
示例回答	“属于账务层数据一致性故障。我会先确认影响范围（时间、账户），然后导出交易明细与账务明细逐笔比对，重点检查‘当日汇总’是否匹配。常见原因是退款流程未同步生成会计分录，或定时任务失败。修复后增加实时借贷校验告警，防止同类问题。”
可能追问	① 如何设计实时借贷校验？ ② 账务系统在分布式下如何保证最终一致？ ③ 对账不平时的SLA处理机制？
避坑提醒	❌ 只查SQL不查日志 ❌ 忽略上游交易数据完整性 ✅ 必须提到“借贷恒等式”是账务核心约束

项目名称	日清日结对账平台
业务背景	日交易量百万级，手工对账需8小时，差账户数不良贷款率飙升
规模指标	日交易流水500万笔，涉及账户300万，差错率0.02%
技术栈	Kafka + Flink + HBase + MySQL + 自研对账引擎
核心难点	毫秒级延迟下保证借贷平衡；分布式流水聚合去重
面试高频追问	① 对账引擎如何保证不丢不重？ ② 借贷平衡校验的算法复杂度？ ③ 差错处理流程（冲正/补单）
可迁移回答话术	“我主导了日清日结对账平台，通过Flink实时聚合交易流水，与会计系统逐笔比对，发现差异后触发补偿任务。核心是设计了一个‘借贷差异窗口’，将不平衡交易打标并自动重算，最终将差错恢复时间从8小时缩短至15分钟。”

⚠️ 备考建议： 本章是故障治理面试的“地图篇”，务必掌握三层故障的不同表现。面试官常将“重复支付”“借贷不平”作为切入点，考察你对整体架构和容错设计的理解。多练习结合项目讲案例。