📚 课程目录第4章高并发与性能优化

4. 高并发与性能优化：高频问题、回答框架、公司侧重点

支付系统高并发场景下，性能优化是面试核心。面试官关注你在流量洪峰下的系统设计能力、瓶颈定位能力、方案权衡能力。本章拆解三大高频考题，并给出可落地的回答框架。

秒杀场景下如何设计高可用支付接口？

    框架： 前端限流 → 后端令牌桶/漏桶 → 消息队列削峰 → 预扣库存+异步对账 → 降级开关
  

接口前端做限流（如滑动窗口），后端部署令牌桶。支付请求先入MQ削峰，消费方预扣库存后异步对账，失败通过补偿任务回滚。同时预留降级开关，极端情况切到简化支付流程。

避坑提醒： 不要只谈“乐观锁”。秒杀场景高冲突下乐观锁回滚率极高，必须结合分布式锁+队列排队。

支付订单状态更新的性能优化如何做？

    框架： 热点状态缓存 → 异步MQ更新DB → 分库分表 → 批量写 → 最终一致性校验
  

对支付中的高频查询状态做本地缓存+Redis，状态变更通过MQ异步写DB。按订单ID取模分库，写操作使用批量update reduce IO。利用binlog监听做最终一致性校验。

避坑提醒： 避免“先删缓存后写DB”的经典错误，会导致并发下缓存穿透。推荐延迟双删或Cache-Aside模式。

支付对账系统性能瓶颈如何定位与优化？

    框架： 预发全链路压测 → 监控P99耗时 → 定位慢SQL/热点路径 → 拆分任务并行 → 线程池参数优化
  

压测发现对账文件读取耗时占比60%，通过explain找到全表扫描索引缺失，加联合索引后降至15%。每天交易记录按渠道拆分为独立任务，用线程池并行处理，并限制单文件行数减少OOM风险。

避坑提醒： 对账系统一定要设计幂等去重，否则重复处理会导致资金错账。切勿只优化SQL而忽略业务逻辑幂等性。

💡 面试策略提示： 回答时先对齐面试官所指业务场景（秒杀/转账/对账），然后按指标→瓶颈→方案→验证节奏展开。不同公司偏好不同——去蚂蚁面侧重“分布式事务”，“去微信面侧重“压测细节”，去字节面侧重“监控与自适应”。