场景设定

• 公司与项目背景:
  某头部电商平台，正在紧急招聘资深Java工程师，以支持其新上线的“AI驱动的智能推荐与秒杀系统”项目。该项目旨在通过AI算法实时分析用户行为并动态调整商品推荐，同时需应对双11等大促期间千万级别的并发请求和数据一致性挑战。

• 角色设定:

• 面试官 (李姐): 该电商平台的架构负责人，拥有10年大型分布式系统经验，擅长用业务痛点反推技术能力，提问直击要害。

• 求职者 (小曾): 一位工作三年的Java开发者，熟悉Spring Cloud全家桶，简历上罗列了Kafka、Redis等热门技术，但实际落地经验有限。

提问的技术栈如下:
Java SE (11), Spring Boot, Spring Cloud Alibaba (Nacos, Sentinel, Seata), Kafka, Redis, MySQL, Elasticsearch, OpenFeign, Sentinel

面试对话实录

第一轮：基础热身与项目破冰

李姐: “小曾，你简历上提到参与过电商秒杀系统，能详细说说当时怎么解决高并发下库存超卖问题的吗？”

小曾: “这个简单，我们用了分布式锁，Redisson来实现的，通过Redis原子性操作SETNX保证互斥，锁超时防止死锁。”

李姐: “不错。那如果Redis挂了，或者网络分区了，你的方案还能保证数据一致性吗？”
小曾: “呃……这个……我们用了Seata分布式事务，通过本地消息表来实现两阶段提交……”

李姐: “Seata真的适合所有场景吗？你分析过其性能损耗吗？”
小曾: “额……这个……主要看业务场景……”

李姐: “好，我们接着聊。你的项目QPS峰值是多少？当时是如何进行流量削峰的？”
小曾: “大概300W QPS，我们用了Kafka+Redis缓存+限流降级……”

李姐: “能具体说说Redis缓存的命中率怎么控制的？过期策略选型依据是什么？”
小曾: “这个……我们根据业务数据波动调整……”

第二轮：系统设计与场景深挖

李姐: “假设现在要给你的系统增加一个实时监控告警功能，你会怎么做？”
小曾: “我会用Prometheus+Grafana监控，设置阈值告警……”

李姐: “很好。如果发现秒杀接口响应超过500ms，你会优先排查哪些环节？线程池满了你会怎么调优？”
小曾: “可能看CPU、内存、慢查询……线程池参数……”

李姐: “那如果Redis缓存雪崩了，你的熔断降级策略覆盖了哪些模块？”
小曾: “秒杀库存、推荐……”

李姐: “好，最后一个问题。如果客户投诉说‘我秒杀了但没减库存’，你会从哪个日志开始排查？”
小曾: “看Seata事务日志、Redis操作日志……”

李姐: “很好。我们今天就到这里。”

第三轮：架构思考与前沿视野

（无深入问题，时间不足）

面试结尾话术:
李姐：“好的，小曾。今天聊的差不多了，我们对你的情况有了基本的了解。你先回去等通知吧，我们会在一周内给你答复。”

技术深度解析

问题1：小曾，你简历上提到参与过电商秒杀系统，能详细说说当时怎么解决高并发下库存超卖问题的吗？

• 考察点: 分布式锁原理、高并发场景下的数据一致性保障。
• 标准答案:
  1. 分布式锁方案:
     • 使用Redisson实现分布式锁，通过SETNX命令确保互斥，并设置合理过期时间防止死锁。
     • 关键点：锁的粒度控制（库存表锁 vs. 商品表锁）、锁的持有时间（秒杀时长+缓冲时间）。
  2. 事务方案:
     • 结合Seata或本地消息表实现分布式事务，确保库存扣减和消息写入的原子性。
     • 优化：采用TCC（Try-Confirm-Cancel）模式或本地消息表+定时补偿。
• 方案对比与权衡:
  • Redis锁 vs. MySQL锁: Redis锁更轻量，但需处理网络分区问题；MySQL锁性能好但扩展性差。
  • Seata vs. 本地消息表: Seata功能完善但开销大；本地消息表轻量但需业务代码侵入。
• 常见陷阱与最佳实践:
  • 避免使用Lua脚本解决锁问题（原子性无法保证）；
  • 锁超时必须大于业务处理时间+网络延迟；
  • 优先考虑乐观锁（版本号）或数据库行锁（高并发场景）。

问题2：如果Redis挂了，或者网络分区了，你的方案还能保证数据一致性吗？

• 考察点: 分布式系统容错设计、分布式事务的边界条件。
• 标准答案:
  1. Redis故障处理:
     • 部署Redis集群或哨兵机制；
     • 秒杀核心逻辑使用MySQL事务+行锁，Redis仅作缓存。
  2. 网络分区处理:
     • Seata的SAGA模式（本地事务+补偿）可降低一致性问题；
     • 关键路径使用2PC（但性能差，需权衡）。
• 方案对比与权衡:
  • 强一致性 vs. 最终一致性: 秒杀场景建议采用最终一致性（如本地事务+补偿）；
  • Seata模式选型: AT模式最稳妥但影响性能；TCC模式需大量业务代码改造。
• 常见陷阱与最佳实践:
  • 忽视Redis主从延迟导致超卖；
  • 补偿事务的幂等性设计（使用Redis或数据库唯一索引防止重复补偿）。

（其他问题解析略，逻辑同上）