阿里巴巴高并发业务系统后端面经

《面试题目》

1. 如何设计每秒万次请求、库存有限的积分抽奖系统？
2. Redis 预扣库存和异步落库时，如何保证奖品概率和库存不超发？
3. 如何保证缓存与数据库最终一致性，强一致场景又该怎么做？
4. 消费端宕机时如何确认消息状态并避免消息丢失？
5. Redis 幂等 key 的过期时间如何设置，处理中 key 过期怎么办？
6. 联合索引的字段顺序如何影响等值查询和扫描范围？
7. TCP 三次握手为什么不能简化为两次？
8. G1 相比 CMS 做了哪些优化，停顿目标设置过小会怎样？
9. 如何设计支持状态码、限流和熔断的大模型 API 网关？
10. SSE 与 WebSocket 有哪些区别，客户端如何重连？
11. 多 Agent 之间选择消息队列还是数据库通信时应考虑什么？
12. 如何为超大无序数组求中位数而不直接排序？
13. ThreadLocal 的底层结构是什么，为什么可能发生内存泄漏？

《参考解析》

1. 抽奖请求先在 Redis 原子扣减库存并记录幂等订单，再异步落库；概率抽样使用预计算的权重表，库存不足时必须回滚或发补偿事件，数据库最终以唯一约束兜底。
2. 常规业务采用更新数据库后删除缓存，并通过重试、订阅变更日志或延时双删收敛一致性。余额、库存等强一致数据应缩短缓存生命周期或直接以数据库事务和版本校验为准。
3. 消费者只有在业务落库成功后确认消息；失败则重试，超过上限进入死信。幂等键的 TTL 应覆盖最大处理与重试时长，处理状态可单独存储并在续期失败时告警。
4. 联合索引遵循最左匹配，等值条件优先缩小范围；把区分度高且常参与过滤的字段放在前面通常能减少扫描，但最终仍需结合查询组合和执行计划验证。
5. 第三次握手同时确认客户端能接收服务端序号，若只有两次，服务端无法确认旧的 SYN 是否重传，容易长期占用半连接资源。
6. G1 按 Region 管理堆并优先回收收益高的区域，可设定停顿目标；目标过小会提高筛选和复制频率，导致吞吐下降甚至频繁 GC。
7. 网关应统一鉴权、配额、超时、限流和熔断，并用请求 ID 贯穿日志。SSE 适合服务端单向事件流，WebSocket 支持双向通信；重连要携带最后事件 ID 或业务游标，保证幂等。
8. 中位数可用快速选择的分区算法，或维护两堆分别保存较小和较大的一半，避免完整排序。ThreadLocalMap 使用弱引用 key、强引用 value，线程长期存活且未清理时 value 可能泄漏，应在 finally 中 remove。