3. 交易系统核心故障类型与根因分析
本章聚焦面试中高频出现的故障分类、排查思路与追问逻辑。你需要掌握故障的体系化分类、标准排查步骤以及如何有逻辑地表达根因分析过程。
故障类型知识结构表
| 故障类别 | 典型表现 | 常见根因 | 排查要点 |
|---|---|---|---|
| 超时/雪崩 | 接口响应慢→调用链超时→级联失败 | DB慢查询、外部依赖超时、线程池阻塞 | trace链路、慢SQL、线程dump |
| 数据不一致 | 对账不平、状态跳变、重复支付 | 分布式事务缺少补偿、MQ重复消费、缓存与DB不同步 | 日志回放、幂等校验、最终一致性方案 |
| 死锁 | 事务超时、CPU飙高、业务卡顿 | 多线程加锁顺序不一致、数据库死锁 | 死锁日志、锁顺序分析、jstack |
| 内存溢出 | OOM、频繁Full GC、服务重启 | 内存泄漏、大对象、GC配置不当 | 堆dump、MAT分析、代码review |
🎯 面试问题
请列举交易系统常见的故障类型，并说明如何分类？
考察点：系统性故障认知能力、分类逻辑、是否覆盖全链路。
回答框架：按“表现-根因-影响”三维分类 → 举例说明每一类 → 总结排查优先级。
示例回答：
我通常按三类划分：①超时类（依赖超时、线程池阻塞）；②数据类（不一致、丢失、重复）；③资源类（内存溢出、死锁）。例如双11大促曾遇到DB连接池耗尽导致接口雪崩，最终通过限流+连接池隔离解决。排查时会优先关注超时类，因为影响面最广。
可能追问：你提到的数据不一致有哪些具体场景？最终一致性如何保证？
避坑提醒：不要只说出“网络、磁盘”等单维度；务必展示“业务级”分类，如支付重复、库存超卖等实际案例。
🎯 面试问题
描述一次你排查交易系统故障的全过程，用了什么方法论？
考察点：排查路径的条理性、工具使用、是否有标准化流程。
回答框架：STAR结构 + 五步法（确认现象→隔离范围→抓现场→分析→验证）。
示例回答：
某次订单超时飙升（S），我首先确认监控看是支付回调接口响应慢（T），隔离出是下游银行网关超时，抓取该时段网关日志发现请求堆积（A），分析系银行一侧限流导致（R），改为异步回调+重试机制验证通过。全程用时30分钟。
可能追问：如果现场日志被覆盖了怎么办？如何避免下次故障？
避坑提醒：不要只讲“看日志-改代码-完事”，要体现方法论（如异常采集、隔离策略、灰度恢复）。
🎯 面试问题
交易系统出现数据不一致时，你会如何定位根因？
考察点：分布式数据一致性理解、排查手段、补偿机制掌握。
回答框架：先看对账结果 → 复现时间线 → 检查事务状态 → 分析MQ可靠性 → 定位补偿或幂等缺失。
示例回答：
先取对账差异记录，找到具体交易ID；通过业务流水还原时间线，发现本地事务提交后MQ消息未成功发送；检查消息表无记录，确认是本地事务与消息发送未保证原子性。解决方案改为事务消息+本地消息表双重保障。
可能追问：你怎么验证消息已成功投递？幂等如何设计？
避坑提醒：不要一开始就推“是程序bug”，要先展示数据对比、日志查询的客观过程，体现严谨性。
💡 讲师提示：面试官常通过“故障类型”判断你的系统边界感。建议在准备时梳理自己负责系统的故障库，每个类型配1-2个实例，回答时自然带出“我遇到过的真实案例”加分。