场景设定

• 公司与项目背景: 某头部电商公司，正在紧急招聘资深Java工程师，以支持其即将上线的大型促销活动。该项目旨在通过高并发处理用户订单、库存同步和优惠券发放，预计将面临巨大的系统压力和数据一致性挑战。
• 角色设定:
  • 面试官 (李姐): 该电商平台的架构师，技术功底扎实，为人严肃但乐于引导，喜欢通过实际业务痛点考察求职者的系统设计能力和技术深度。
  • 求职者 (小曾): 一位工作三年的Java开发者，对各种新技术名词如数家珍，简历光鲜，口头禅是“这个我了解，不就是那个XXX嘛”，但缺乏系统性的思考和实践。

提问的技术栈如下：

Java SE (8/11/17), Jakarta EE, JVM, Maven, Gradle, Spring Boot, Spring MVC, Spring WebFlux, MyBatis, Hibernate, JPA, HikariCP, Redis, Kafka, RabbitMQ, Spring Cloud, OpenFeign, Resilience4j, Spring Security, JWT, OAuth2, Log4j2, Prometheus, ELK Stack, Docker, Kubernetes

面试对话实录

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

李姐: “小曾，先说说你在上一家公司负责的那个高并发订单系统，用了哪些技术？高峰期QPS大概是多少？”

小曾: “主要用了Spring Boot和MyBatis，数据库是MySQL，缓存用了Redis，消息队列是Kafka。高峰期QPS能到几万吧，具体数字忘了。”

李姐: “几万QPS？能支撑住促销活动的百万级流量吗？你当时是怎么解决库存超卖问题的？”

小曾: “库存超卖… 嗯… 我们用了分布式锁，Redis的SETNX命令实现的。不过Redis集群的话，锁的可靠性会有点问题…”

李姐: “分布式锁的可靠性问题你具体怎么考虑的？比如网络分区或客户端崩溃的情况。”

小曾: “这个… 我觉得可以用Redis的Lua脚本保证原子性吧… 但好像还是有点复杂…”

李姐: “不错，思路是对的。但Lua脚本写错也可能导致问题，你有没有考虑过其他方案？比如数据库层面的锁或消息队列确保顺序？”

---

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

李姐: “假设用户下单后，需要同步扣减库存和发放优惠券，这两个操作必须原子性完成，你会怎么设计？”

小曾: “我会用分布式事务，比如Seata框架，或者本地消息表+定时任务补偿… Seata好像有点重，本地消息表的话延迟可能比较大。”

李姐: “Seata的原理你了解吗？TCC和SAGA两种模式各有什么优缺点？”

小曾: “TCC是先执行所有补偿操作，SAGA是异步补偿… TCC阻塞大，但可靠；SAGA轻量但可能丢失事务…”

李姐: “那在高并发场景下，你会优先考虑哪种方案？为什么？”

小曾: “我觉得SAGA可能更适合… 因为TCC需要全局协调，太重了…”

李姐: “但SAGA的最终一致性怎么保证？如果定时任务失败呢？”

小曾: “这个… 可能需要增加监控和告警吧…”

李姐: “对，但监控和告警只是治标不治本。有没有更根本的方案？”

小曾: “呃… 看起来我有点没思路了…”

---

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

李姐: “你们项目里有没有用到AIGC技术？比如生成个性化优惠券文案？”

小曾: “我们确实在研究AIGC，用了一些开源模型，比如OpenAI的Embedding API… 但效果还有点不稳定，经常出现幻觉问题。”

李姐: “幻觉问题具体指什么？模型生成的文案不准确吗？”

小曾: “对，有时候会生成重复或无意义的文本… 我们尝试增加提示词，但效果一般…”

李姐: “那你觉得怎么解决这个问题？比如RAG（检索增强生成）方案你了解吗？”

小曾: “RAG… 听起来像检索+生成… 但具体怎么结合我还没深入研究…”

李姐: “所以你的技术视野还有提升空间。比如向量数据库和语义检索，在AIGC场景里能怎么应用？”

小曾: “这个… 我回去可以看看资料…”

李姐: “好的，继续学习。今天的面试就到这里吧。”

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

---

技术深度解析

问题 1：电商高并发场景下如何解决库存超卖问题？

• 考察点: 分布式锁的原理、可靠性问题和替代方案。
• 标准答案:
  1. Redis分布式锁: 使用SETNX命令加锁，但需用Lua脚本保证原子性，并设置过期时间防止死锁。
  2. 数据库锁: 通过表级或行级锁保证库存扣减的原子性，但性能较差，不适合高并发。
  3. 消息队列确保顺序: 用户下单请求进入Kafka，消费者按顺序处理库存和优惠券，但需解决消息重复和丢失问题。
• 方案对比与权衡:
  • Redis锁轻量但需注意网络分区问题；数据库锁可靠但性能瓶颈明显；消息队列解耦但实现复杂。
• 常见陷阱与最佳实践:
  • 避免使用简单SETNX加锁，必须用Lua脚本；考虑超时重试机制；优先选择业务无状态化设计。

问题 2：如何设计原子性扣减库存和发放优惠券的分布式事务？

• 考察点: 分布式事务原理、Seata和本地消息表的优缺点。
• 标准答案:
  1. Seata (TCC/SAGA):
     • TCC: 全局协调，先执行所有补偿操作，可靠性高但阻塞大。
     • SAGA: 异步补偿，轻量但可能丢失事务，适合最终一致性场景。
  2. 本地消息表+定时补偿: 简单易实现，但延迟和可靠性差，适用于补偿不敏感的业务。
• 方案对比与权衡:
  • TCC适合强一致性场景（如金融），SAGA适合电商等容忍丢失的业务。
• 常见陷阱与最佳实践:
  • 避免过度使用Seata，优先考虑业务无状态化或本地化补偿；监控事务成功率并设置重试。

问题 3：AIGC场景下的幻觉问题如何解决？

• 考察点: RAG原理、向量数据库和语义检索的应用。
• 标准答案:
  1. RAG (检索增强生成): 结合外部知识库（如向量数据库）和生成模型，减少幻觉。
  2. 向量数据库: 存储企业文档或知识图谱的向量表示，通过语义相似度检索相关内容。
  3. 提示词优化: 调整生成模型的提示词，明确约束条件。
• 方案对比与权衡:
  • RAG结合了检索和生成，效果优于纯生成；向量数据库需预训练和索引优化。
• 常见陷阱与最佳实践:
  • 避免直接依赖生成模型输出，必须结合业务逻辑校验；定期更新知识库以减少过时信息。