面试评分表与自我评估工具：高频问题、回答框架、公司侧重点
本章价值： 教你用面试官视角构建“能力自检表”，把高频问题拆成可复用的回答框架，同时摸清大厂在交易系统面试中的隐性评分点。核心产出：一套“问题→框架→示例→避坑”的即查即用卡片。
路径解读： 从接收问题开始，先拆解关键字（比如“高并发”“订单一致性”“分库分表”），然后选择框架（STAR、4+1视图、问题→方案→对比），最后结构化输出并插入加分亮点（如性能数据、架构演进路径），最后避坑确认（避免只讲理论不讲实战）。
高频问题分类与自检清单
| 问题类型 | 典型问题 | 自检核心 |
|---|---|---|
| 系统设计 | 设计一个秒杀交易系统 | 是否包含流量削峰、库存预热、防超卖 |
| 一致性 | 如何保证订单最终一致性 | 是否说清本地消息表 vs 事务消息 |
| 高可用 | 交易链路降级策略 | 是否有真实停顿/熔断案例 |
| 性能调优 | 某接口耗时优化 | 能否给出具体瓶颈分析与改进数值 |
三个面试问答卡片
📌 问题：请设计一个高并发下单系统，保证库存不超卖
面试官考察点：
- 是否理解数据库锁与缓存扣减的优劣
- 能否讲清“预扣-确认-回滚”流程
- 对分布式事务的掌握深度
回答框架（建议）： 四步法：1）前端限流（令牌桶）；2）库存预热到 Redis，用 Lua 脚本原子扣减；3）异步消息订单，本地消息表保证最终一致；4）冲突时对账补偿。
简短示例回答： “我会先通过 Nginx+Guava 限流，将库存分片存到 Redis 并用 Lua 脚本执行扣减；扣减成功后发送 MQ，消费端落库订单并触发对账，确保库存与订单数最终一致。”
可能追问： Redis 扣减后宕机怎么办？库存分片如何保证均匀？是否考虑热点 Key？
🚫 避坑提醒： 不要只说“用 Redis 扣库存”，要主动提及最终一致性补偿方案；避免空泛讲“分布式锁”，要具体讲锁粒度与性能损耗。
📌 问题：你的项目经历过哪些异常场景，如何保证数据一致性？
面试官考察点：
- 是否有实际线上故障处理经验
- 对幂等性、重试、回滚机制的理解
- 能否量化影响范围与恢复时间
回答框架（建议）： STAR 结构：S（场景）→ T（任务）→ A（方案：幂等表、状态机、补偿事务）→ R（结果：数据零丢失或秒级恢复）。
简短示例回答： “某次大促 MQ 集群脑裂导致订单回调丢失，我们立即启用本地消息表重放 + 人工对账，同时为每个订单生成唯一流水号保证幂等，最终 15 分钟内恢复，零数据丢失。”
可能追问： 幂等表如何设计主键？重试导致的重复扣款怎么处理？
🚫 避坑提醒： 避免只说“我们用了事务消息”，要结合具体异常类型；对重试次数、补偿时效要有明确数据。
📌 问题：你认为交易系统研发最核心的能力是什么？
面试官考察点：
- 对交易本质的理解（安全、可靠、可追溯）
- 是否具备架构演进思维
- 沟通与取舍能力
回答框架（建议）： 三角模型：一致性保证（技术）→ 容错设计（工程）→ 业务理解（产品）。
简短示例回答： “我认为核心是‘在复杂业务中做对的技术取舍’。比如用户下单要快，但资金对账必须强一致；我通常用最终一致性加定时对账，性能与可靠性平衡。”
可能追问： 如果业务要求强一致且高并发，你会怎么设计？
🚫 避坑提醒： 不要只谈技术不谈业务，要用具体例子说明取舍逻辑；避免把“分布式事务”当作万能方案。
公司侧重点速查
| 公司类型 | 侧重点 | 高频关键词 |
|---|---|---|
| 电商大厂 | 海量订单处理、秒杀、库存一致性 | Redis/Lua、本地消息表、限流降级 |
| 金融/支付 | 资金安全、对账、审计、状态机 | TCC、SAGA、幂等、日切 |
| 第三方支付 | 多渠道路由、退款、差错处理 | 异步对账、补偿任务、流水号 |
自我评估工具使用建议： 对照上述表格，每道题问自己：我能否用一句话点出公司侧重点？比如面试金融公司，回答中主动提及“SAGA 模式”和“幂等表”会比只说“Redis 扣库存”得分更高。