Java 17 Spring Boot Kafka Redis互联网大厂电商场景面试实录燕双非的三轮拷问场景互联网大厂电商技术岗面试人物严肃面试官、搞笑水货程序员燕双非第一轮订单与库存的高并发设计面试官假设你负责一个秒杀活动用户下单量瞬时暴涨。你会先从哪些技术点入手燕双非我会先把 Spring Boot 项目起起来然后用 Redis 做库存预扣Kafka 异步削峰保证数据库别直接被打爆。面试官不错方向是对的。那你说说为什么不用同步扣库存直接落库燕双非因为同步的话大家一起挤数据库可能会把 MySQL 挤成早高峰地铁。我一般会先在 Redis 里做原子扣减再把消息发到 Kafka后面异步生成订单。面试官很好至少你知道“先挡流量再落库”。那如果 Kafka 消息重复消费了怎么办燕双非嗯……重复就重复吧反正人类也会重复点刷新。技术上应该是做幂等比如订单号唯一索引、消费记录表、或者 Redis 去重。面试官回答得还可以说明你不是完全靠感觉写代码。面试官再说说 MyBatis 和数据库连接池你会怎么选燕双非MyBatis 比较适合订单、库存这种 SQL 可控的场景HikariCP 连接池性能也更稳别拿 C3P0 去扛大促容易被老板追着打。第二轮会员、支付与风控链路面试官电商订单创建后接下来是支付、优惠券、风控、通知。你怎么设计接口鉴权和安全方案燕双非可以用 Spring Security JWT。用户登录后签发 token前后端分离时每次请求带上 token网关或过滤器校验即可。面试官JWT 的优点和风险各是什么燕双非优点是无状态扩容方便风险是 token 一旦签发撤销不太方便得配合黑名单、短过期时间和刷新机制。面试官很好。那支付回调的幂等怎么做燕双非支付回调可能会重试所以订单状态更新要做幂等控制比如只允许从“待支付”流转到“已支付”并且通过唯一流水号防止重复入账。面试官继续。风控系统要怎么做实时拦截燕双非可以把用户画像、下单频率、设备指纹之类的数据实时汇总配合规则引擎或者简单策略判断。复杂一点可以走 Kafka 流式处理或者接入独立风控服务。面试官还行已经开始像个做过业务的人了。那如果支付链路里要加审计日志和性能监控呢燕双非日志用 Logback 或 SLF4J 统一输出监控可以接 Micrometer再把指标上报到 Prometheus 和 Grafana。慢接口再用链路追踪看一下可能是数据库慢也可能是 MQ 堆积。面试官不错至少你知道不是让用户“耐心等待”就能解决问题。第三轮商品搜索、推荐与实时互动面试官现在我们要做商品搜索和实时推荐还要支持前台客服与用户在线沟通。你会怎么设计燕双非搜索可以用 Elasticsearch 做商品索引推荐可以结合用户行为日志和简单画像。实时沟通可以用 WebSocket客服端和用户端建立长连接。面试官如果搜索结果要支持高亮、分页和排序你会怎么考虑燕双非高亮和分页是 ES 的基本操作排序要结合热度、销量、价格等字段。分页别深翻页太狠不然 ES 也会喘。面试官那推荐里的埋点数据怎么传燕双非前端埋点先发到后端再通过 Kafka 进入日志或行为分析链路。后面可以做离线统计也可以做实时计算。面试官客服聊天呢你怎么保证消息不丢燕双非WebSocket 负责实时推送消息落库做持久化必要时结合 Redis 记录在线状态。断线重连后还能补发未读消息不然客服一句“在的亲”发出去用户没收到就尴尬了。面试官最后一个问题如果你的接口里要支持文档式 API 管理和自动生成说明你会用什么燕双非Swagger/OpenAPI方便前后端联调也方便测试和维护。面试官行今天就到这里吧。你回家等通知吧。面试问题详细解答1. 秒杀场景为什么要用 Redis 预扣库存 Kafka 异步下单秒杀活动的核心矛盾是“瞬时流量远大于系统平均承载能力”。如果请求直接同步写数据库数据库会因为锁竞争和连接耗尽而成为瓶颈。Redis 适合做高并发原子操作可以先做库存预扣Kafka 适合做消息缓冲和削峰填谷把下单请求异步化后端消费者再慢慢落库。这样可以把高峰压力从数据库转移到缓存和消息队列系统更稳定。2. Kafka 消息重复消费如何处理消息队列通常只保证至少一次投递因此重复消费是常见问题。常见做法包括业务幂等设计、数据库唯一约束、消费日志表、Redis 去重键、状态机控制等。比如订单创建接口可以基于业务单号做唯一索引消费者收到重复消息时插入失败或直接忽略从而避免重复下单。3. 为什么电商订单链路常用 MyBatis 而不是完全依赖 JPA电商订单、库存、支付等核心链路往往对 SQL 可控性、性能和复杂查询要求较高。MyBatis 更适合显式编写 SQL便于做索引优化、分库分表适配和复杂条件查询。JPA 更偏向对象关系映射开发效率高但在复杂业务场景里有时不如 MyBatis 透明可控。实际项目里也常混合使用