日期：2026-07-12
标签：#面试 #八股 #后端 #第三方接口 #异步处理 #场景题
一句话答案
可以使用 MQ 做削峰、解耦和可靠重试，但要先确认业务是否允许最终一致、是否需要顺序和第三方限额；不用 MQ 可采用数据库任务表、线程池、调度平台或事件流。
面试口语版
接入请求先做鉴权、参数校验和幂等落库，再返回 taskId；后续由 MQ 消费者调用第三方，适合耗时长、可异步且需要削峰的场景。设计时要考虑至少一次投递导致的重复、第三方幂等键、顺序、限流、超时、重试、死信、回调和状态查询。若量不大，可用数据库任务表加 SKIP LOCKED/租约抢任务，优点是事务边界简单；只需进程内短异步可用有界线程池，但宕机会丢任务；定时批处理可用调度平台。关键交易不应只放内存。
方案对比
| 方案 | 优点 | 风险/适用 |
|---|---|---|
| MQ | 削峰、解耦、扩展好 | 重复、积压、运维成本 |
| 数据库任务表 | 事务简单、易查询 | 轮询和数据库压力 |
| 本地线程池 | 简单、低延迟 | 宕机丢、容量有限 |
| 调度平台 | 批任务治理 | 实时性较弱 |
关键细节
- 异步受理成功不等于第三方处理成功，状态应为处理中。
- 重试前先判断错误是否可重试，未知结果先查询。
- 队列积压必须有容量、过期和用户可见状态。
- 第三方限流应由消费者全局协调，而不是无限扩容消费实例。
面试官追问
- MQ 重复消费如何避免第三方重复执行？
- 数据库任务表如何避免多个 Worker 重复领取？
- 什么情况不适合异步？
面试官追问参考答案
1. MQ 重复消费如何避免第三方重复执行？
每个业务任务使用稳定幂等键，本地先按唯一键记录执行状态，第三方调用也携带其支持的幂等号。超时后先查询原请求结果，不能换新请求号盲目重试。
2. 数据库任务表如何避免多个 Worker 重复领取？
使用状态条件更新、SELECT ... FOR UPDATE SKIP LOCKED 或带过期时间的租约领取，只有更新成功者执行。任务完成和失败转移也用版本号，租约过期后其他 Worker 可接管，执行本身仍需幂等。
3. 什么情况不适合异步？
用户必须立即依赖结果完成下一步、操作不可补偿且第三方无幂等/查询能力、或业务要求强同步一致时，不宜简单异步。可以同步关键最小步骤，非关键副作用再异步化。
学习清单
- 能比较 MQ、任务表与线程池。
- 理解异步任务状态和第三方幂等。
Maintained by · YihuiEdit on GitHub