场景设定

• 公司与项目背景: 某头部电商平台，正在紧急招聘资深Java工程师，以支持其即将到来的“双十一”大促项目。该项目涉及海量订单处理、秒杀活动、库存同步等高并发场景，对系统的稳定性、性能和可扩展性要求极高。
• 角色设定:
  • 面试官（李姐）: 该电商平台的架构负责人，技术经验丰富，擅长通过实际业务场景考察求职者的系统设计能力和抗压能力。
  • 求职者（小曾）: 一位工作三年的Java开发者，对分布式系统有理论认识，但缺乏大型项目实践经验，口头禅是“这个我了解，不就是那个XXX嘛”。

提问的技术栈

Java SE, Spring Boot, Spring Cloud, Kafka, Redis, MySQL, MyBatis, 分布式锁, 分布式事务, Seata, HikariCP, ELK

面试对话实录

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

李姐: “小曾，看到你简历里提到参与过电商秒杀项目，能详细介绍一下你们当时如何解决高并发下的库存超卖问题的吗？”

小曾: “我们当时用了分布式锁，Redis的SETNX命令，保证一个用户同一时间只能购买一个商品。”

李姐: “很好，思路是对的。那如果Redis宕机或者网络分区，这个方案还能保证库存不超卖吗？”

小曾: “呃……这个……可能需要加个降级机制，比如使用数据库锁或者本地缓存……”

李姐: “不错。那如果多个Redis节点分区，你的锁如何保证是全局唯一的？”

小曾: “这个我还没考虑过……可能需要配合Redis集群的槽位机制？”

李姐: “思路是对的，但实际落地时需要注意锁的自动续期和超时处理，否则在高并发下容易发生锁丢失。”

李姐: “再问一个，你们秒杀系统如何保证订单和库存的最终一致性？”

小曾: “我们用了Seata分布式事务，确保订单和库存操作要么都成功，要么都回滚。”

李姐: “Seata的原理了解吗？TCC、SAGA、AT哪种更适合秒杀场景？”

小曾: “呃……SAGA好像更适合，因为TCC太重了，AT可能对数据库改动要求太高……”

李姐: “不错，能具体说说SAGA如何解决幂等性和阻塞问题吗？”

小曾: “就是加分布式锁或者数据库版本号……”

李姐: “很好，继续。”

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

李姐: “假设你的系统需要处理每秒10万笔订单请求，你会如何设计数据库架构和缓存策略？”

小曾: “数据库用分库分表，缓存用Redis集群，热点商品数据用本地缓存预热……”

李姐: “分库分表你会用Sharding-JDBC吗？如果遇到热点数据分片不一致，如何解决？”

小曾: “这个……可能需要加全局ID生成器……”

李姐: “思路是对的。那Redis集群的读写分离怎么做？如果写入压力特别大，你会考虑Redis Cluster的哪些优化？”

小曾: “Redis Cluster分片后写入会跨多个节点，性能会下降……可能需要加异步写入队列……”

李姐: “很好。再问一个，如果系统需要支持秒杀活动中的消息推送（如短信、微信），你会如何设计消息队列？Kafka和RabbitMQ哪个更适合？”

小曾: “Kafka吧，因为吞吐量更大……”

李姐: “Kafka确实吞吐量高，但它的消息有顺序保证吗？如果秒杀消息乱序，会导致什么问题？”

小曾: “呃……可能需要业务方自己用时间戳或者商品ID排序……”

李姐: “没错。那如果Kafka宕机，如何保证消息不丢失？你了解它的Exactly-Once语义吗？”

小曾: “需要开启幂等性消费和事务性生产，但这样性能会下降……”

李姐: “没错，权衡点就在这里。继续。”

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

李姐: “假设你的系统需要集成AI推荐引擎，实时根据用户行为推荐商品，你会如何设计数据同步方案？”

小曾: “用Kafka同步用户行为数据，推荐系统用Flink实时计算……”

李姐: “Flink的窗口计算如何应对秒杀这种瞬时流量激增的场景？”

小曾: “可能需要调整窗口大小和延迟……”

李姐: “很好。再问一个，如果用户反馈推荐结果不准确（AI幻觉），你会如何优化？”

小曾: “可能需要增加人工审核，或者优化模型训练数据……”

李姐: “没错。最后一个问题，如果公司决定用AIGC技术生成商品描述，你会如何设计这个功能模块？”

小曾: “用Spring AI集成OpenAI API，用向量数据库存储商品 Embedding，通过语义检索匹配相似描述……”

李姐: “思路是对的。那如何保证AI生成内容的准确性和合规性？”

小曾: “可能需要加人工审核，或者用RAG技术结合知识库进行检索增强……”

李姐: “很好，你的技术视野不错。今天聊的差不多了，你先回去等通知吧，我们会在一周内给你答复。”

技术深度解析

问题1：如何解决高并发下的库存超卖问题？

• 考察点: 分布式锁的实现原理、Redis应用场景、高并发容错能力。
• 标准答案:
  1. Redis SETNX+EXPIRE:
     • 优点：简单高效，适合低并发场景。
     • 缺点：无法自动续期，在高并发下容易超时释放。
  2. Redis 分布式锁框架:
     • 使用Redlock算法，通过多个Redis节点实现锁的可靠性。
     • 需要处理网络分区和自动续期问题。
  3. 数据库锁+乐观锁:
     • 先加行锁扣库存，再执行乐观锁校验，保证原子性。
     • 适合库存量不大的场景。
• 方案对比与权衡:
  • Redlock vs Redis单节点锁: Redlock更可靠，但需要更多Redis节点和复杂的逻辑。
  • 数据库锁 vs Redis锁: 数据库锁事务性更强，但Redis锁性能更好。
• 常见陷阱与最佳实践:
  • 避免使用单Redis节点实现分布式锁。
  • 锁超时时间需大于业务处理时间，并设置自动续期。

问题2：如何保证订单和库存的最终一致性？

• 考察点: 分布式事务的实现原理、业务场景选型能力。
• 标准答案:
  1. Seata SAGA模式:
     • 将业务流程拆分为本地事务，通过消息队列异步协调。
     • 优点：实现简单，不依赖数据库特性。
     • 缺点：无法保证强一致性，可能出现数据不一致。
  2. TCC（Try-Confirm-Cancel）模式:
     • 对每个步骤实现try、confirm、cancel方法，确保原子性。
     • 优点：强一致性，但实现复杂。
     • 缺点：对业务侵入性高，性能较差。
  3. 本地消息表+补偿事务:
     • 将事务信息存入本地表，通过定时任务或消息队列补偿。
     • 优点：简单可靠，但需要额外补偿机制。
• 方案对比与权衡:
  • SAGA vs TCC: SAGA更适合秒杀场景，TCC适合金融系统。
  • Seata vs 本地消息表: Seata功能更全，但本地消息表更简单。
• 常见陷阱与最佳实践:
  • 避免过度依赖分布式事务，优先使用本地事务+补偿机制。
  • 保证补偿事务的幂等性。

问题3：如何设计高并发数据库架构和缓存策略？

• 考察点: 数据库分库分表、缓存架构设计、性能优化能力。
• 标准答案:
  1. 数据库分库分表:
     • 使用ShardingSphere或MyCAT实现水平分表，按商品ID或用户ID分片。
     • 热点数据分片不一致问题：
       • 使用全局ID生成器（如Twitter Snowflake）。
       • 热点表独立部署，避免跨分片查询。
  2. 缓存架构:
     • 热点数据（商品信息、库存）存入Redis集群，使用分片或Hash模式。
     • 本地缓存预热：通过定时任务或消息队列同步数据。
     • 缓存穿透优化：布隆过滤器+空值缓存。
• 方案对比与权衡:
  • 分库分表 vs 分区查询: 分库分表更彻底，但运维复杂。
  • Redis Cluster vs 单节点: Cluster性能更好，但需要更多节点和分片管理。
• 常见陷阱与最佳实践:
  • 避免缓存雪崩，设置合理的过期时间和预热机制。
  • 分布式锁和缓存需要配合使用，防止超卖。

问题4：如何设计AI推荐引擎的数据同步方案？

• 考察点: 实时计算、AI应用架构能力。
• 标准答案:
  1. 数据采集层:
     • 用户行为数据（点击、加购）通过Kafka实时采集。
     • 商品信息存入Elasticsearch，支持快速检索。
  2. 实时计算层:
     • 使用Flink或Spark Streaming计算用户画像和推荐候选集。
     • 通过Redis缓存推荐结果，降低数据库压力。
  3. AI模型层:
     • 使用Spring AI集成OpenAI API，根据用户行为生成推荐文本。
     • 向量数据库（如Milvus）存储商品 Embedding，支持语义检索。
• 方案对比与权衡:
  • Flink vs Spark Streaming: Flink延迟更低，但配置复杂。
  • OpenAI vs 自研模型: OpenAI效果更好，但成本高。
• 常见陷阱与最佳实践:
  • 保证数据采集的实时性和准确性，避免推荐延迟。
  • AI生成内容需人工审核，防止幻觉问题。