Java面试实战Spring Boot Kafka Redis Elasticsearch 在电商秒杀与搜索推荐场景的三轮深挖场景设定某互联网大厂电商平台围绕秒杀、订单、搜索推荐、库存一致性展开面试。第一轮基础与业务理解面试官我们先从电商秒杀开始。假设高峰期有 10 万人同时抢一件商品你会怎么设计接口和整体链路燕双非先做限流再做缓存接口要快能不查数据库就不查数据库。先把商品信息放 Redis库存也放 Redis用户请求先判断是否还有库存。面试官不错至少方向是对的。那如果 Redis 库存扣减成功但数据库扣减失败怎么处理燕双非嗯……可以先记个日志后面补偿一下或者发个消息让别的服务去处理。面试官补偿思路是对的说明你知道最终一致性。那消息队列你会怎么选为什么燕双非我觉得 Kafka 比较常见吞吐高适合秒杀这种大流量场景。面试官可以至少知道 Kafka 适合高吞吐异步削峰。继续。面试官Spring Boot 里你如何控制接口幂等性防止用户重复下单燕双非可以给每次请求一个 token提交时校验一次成功后删除 token。或者用数据库唯一索引限制重复插入。面试官回答得不错说明你不是完全靠运气写代码。第二轮中间件与一致性面试官现在我们把链路拉长。用户下单后订单服务要通知库存、优惠券、搜索推荐系统一起更新。你如何保证这些系统之间的数据一致性燕双非可以用消息队列订单成功后发一个订单创建消息库存、券、推荐系统分别订阅处理。处理失败就重试。面试官很好。那如果某个消费者重复消费了消息会不会把库存扣两次燕双非这个……应该在消费者侧做幂等比如用业务唯一键查一下处理过就跳过。面试官对。那在 Spring Boot 中实现消息消费幂等你会怎么做燕双非可以把消息 ID 存 Redis或者落库做消费记录。消费前先查存在就不处理。面试官可以。那 Redis 适合做什么不适合做什么燕双非适合做缓存、计数、分布式锁、会话存储。它快但是内存贵不适合放特别大的冷数据。面试官说得还行。那如果秒杀时 Redis 被打爆了你会怎么降级燕双非可以做本地缓存、限流、熔断必要时直接返回活动火爆让用户稍后再试。面试官这就有点大厂味道了至少知道保护系统。面试官你刚才提到搜索推荐系统。假设商品下架后Elasticsearch 里的索引要同步删除你怎么做燕双非还是发消息异步更新索引。ES 不是主库主库变更后由异步任务同步。面试官很好知道 ES 适合检索不适合作为强一致主库。第三轮扩展与工程化面试官最后一轮讲讲你怎么在生产环境里排查一个“下单成功但页面显示库存没变”的问题。燕双非先看日志再看链路追踪最后查消息有没有堆积。要是有 Prometheus 指标告警也一起看。面试官不错排查顺序基本合理。你会重点看哪些指标燕双非接口耗时、QPS、错误率、Kafka 积压、Redis 命中率、数据库慢查询、ES 同步延迟。面试官很好。那如果你要把这个系统容器化部署你会关注什么燕双非Docker 镜像要瘦配置要外置Kubernetes 里要配健康检查、资源限制、滚动发布。面试官这回答算是合格。那 Spring Security 你会怎么保护订单接口燕双非用 JWT 做登录态配合 Spring Security 鉴权用户只能访问自己的订单。面试官可以。那如果要做运营后台的权限管理呢燕双非可以做角色权限控制像管理员、运营、客服不同角色不同接口权限。面试官好今天就到这。整体上你对业务链路有些认识但深度还差点。你先回去等通知吧。面试题详细解答1. 秒杀高并发链路如何设计秒杀场景的核心目标不是“立刻下单”而是“快速接住流量并保护核心系统”。典型做法是静态化商品详情、热点数据缓存到 Redis、接口限流、库存预扣、异步下单、消息队列削峰、最终落库。业务上用户点击秒杀后先校验活动资格与 token再在 Redis 里做库存预扣成功后立即返回“排队中”。后端通过 Kafka 异步处理创建订单、扣减真实库存、通知券系统和推荐系统。这样能显著降低数据库压力。2. Redis 预扣库存与数据库扣减失败如何处理Redis 适合作为高并发入口的“快速裁判”数据库作为最终事实来源。如果 Redis 预扣成功但数据库失败需要通过消息补偿、事务消息、定时对账或人工兜底恢复状态。不要依赖单点同步调用否则在高峰期容易把链路拖垮。3. 如何保证下单流程幂等幂等是防止重复提交和重复消费的关键。常见方式包括前端提交 token后端一次性校验并删除数据库唯一索引约束如 user_id sku_id activity_id消息消费幂等表记录 messageId 或业务单号分布式锁控制同一用户同一商品的重复请求。在电商场景中推荐“业务唯一键 数据库约束 消费幂等表”组合使用可靠性更高。4. 为什么秒杀场景常用 KafkaKafka 适合高吞吐、可水平扩展、消费组模型成熟的场景。秒杀需要在瞬间吸收大量请求并异步处理Kafka 能很好承担“流量缓冲池”的角色。它并不负责强事务一致性而是负责削峰填谷与事件驱动。5. 消息重复消费如何处理消息中间件通常只能保证“至少一次”或“尽力一次”重复消费是常态。消费者侧应该具备幂等能力例如落库前查询是否已处理使用唯一键避免重复写入记录消费状态并加状态机控制对外部调用设计重试安全的补偿逻辑。在库存系统中如果同一订单消息重复到达必须确保只扣一次库存。6. Redis 适合做什么不适合做什么Redis 适合缓存热点数据、分布式锁、计数器、排行榜、会话、限流等。它不适合存放超大冷数据也不适合承担强事务主库职责。原因在于内存成本高、持久化不是它最强的地方、复杂查询能力弱。在电商业务中商品详情、库存标记、用户购物车、验证码都很适合放 Redis。7. ES 索引同步为什么要异步Elasticsearch 的定位是检索引擎不是交易主库。商品上下架、标题修改、价格变更等操作应先落数据库再通过消息或同步任务更新 ES 索引。这样既保证主流程稳定又能获得良好的搜索体验。如果对时效性要求很高可以采用消息驱动的增量同步如果要求简单可靠也可以定时全量修正。8. 如何排查“订单成功但库存没变”排查思路一般是看日志、看链路、看消息堆积、看数据库、看缓存、看同步任务。重点指标包括接口耗时、错误率、Kafka lag、Redis 命中率、数据库慢查询、ES 同步延迟、告警记录等。业务上要明确“页面库存显示”和“真实库存扣减”可能不是同一条链路页面展示可能依赖缓存或搜索系统最终一致性延迟会导致短暂不一致。9. Docker 和 Kubernetes 在这个系统里的作用是什么Docker 负责环境一致性Kubernetes 负责弹性伸缩、健康检查、滚动发布、资源隔离。对于秒杀活动K8s 可以提前扩容应用实例配合 HPA 和限流策略避免单机被打爆。生产部署中还要注意配置外置、日志采集、探针设置、优雅停机和连接池回收。10. Spring Security JWT 如何保护订单接口JWT 用于无状态身份认证Spring Security 负责认证和授权拦截。订单接口应按用户身份和资源归属做权限校验防止越权查询和操作。后台管理接口则通常按角色、权限点、数据范围控制。如果是互联网大厂还会进一步结合风控策略、设备指纹、行为分析做安全加固。总结这场面试的核心不是背概念而是把高并发、缓存、消息队列、搜索、幂等、一致性、监控、容器化、安全串成完整业务闭环。真正的面试回答应该围绕业务目标、风险点、技术选型和兜底方案展开。希望这篇文章能帮助大家在 Java 面试中更好地理解电商高并发链路和常见中间件的实际作用。感谢阅读祝大家面试顺利、早日拿到心仪的 Offer