谢飞机面试记：Spring Boot + Kafka + Redis 在电商秒杀场景中的技术连环问

谢飞机面试记Spring Boot Kafka Redis 在电商秒杀场景中的技术连环问面试官严肃、眼神锐利、笔记本上画着时序图谢飞机格子衫双肩包坐下前先擦了三遍椅子简历写着“精通Spring全家桶除源码” 第一轮秒杀基础架构 —— “你真用过Spring Boot写高并发”面试官翻开简历你们项目里做618秒杀QPS 5万用的什么技术栈谢飞机挺直腰板Spring Boot 2.7我写了RestController加了Valid校验用户ID和商品ID还用了Lombok一行代码搞定Data✅ 面试官点头嗯注解用得熟——那Controller层怎么防刷谢飞机加了RateLimit…啊不是是用拦截器Redis计数器每分钟最多5次请求✅ 面试官微笑不错知道用Redis做限流。那——如果同一用户反复抢同一个商品你怎么保证只扣一次库存谢飞机挠头呃…我用synchronized(this)锁住service方法…❌ 面试官皱眉单机OK集群呢谢飞机小声那…加个分布式锁Redis…setnx✅ 面试官勉强及格——下一题库存扣减成功后订单怎么生成同步还是异步谢飞机当然是同步new Order() → orderDao.insert() → return success❌ 面试官合上本子…你刚说QPS 5万DB扛得住吗⚡ 第二轮削峰填谷 —— “Kafka不是用来发日志的”面试官打开架构图我们把订单创建拆成两阶段预占库存 → 异步落单。用什么解耦谢飞机自信RabbitMQ我配过application.ymlexchange type是directroutingKey是order.create…✅ 面试官很好但为什么不用Kafka谢飞机卡壳Kafka…吞吐高…好像比RabbitMQ快一点❌ 面试官不只是快。它有分区、副本、ISR机制能支撑百万级TPS写入更重要的是——顺序性保障。比如用户A的3次下单请求必须按时间顺序处理否则可能超卖。RabbitMQ单队列是FIFO但集群下多消费者无法保证全局有序而Kafka通过指定partition key如userId让同用户请求进同一分区天然保序。谢飞机恍然哦所以key设成userId就能串行处理✅ 面试官对。那消息失败怎么办谢飞机重试…重试三次再进死信队列✅ 面试官追问重试时发现库存已扣完怎么避免重复下单谢飞机憋红脸…加唯一索引订单号MD5去重✅ 面试官接近了——更优解是幂等性设计用Redis记录「用户商品活动ID」的已处理标识SETNX 过期时间消费前先校验通过才落库。 第三轮缓存攻防战 —— “Redis不是万能钥匙”面试官画出缓存穿透/击穿/雪崩三连图秒杀商品详情页缓存怎么设计谢飞机用Redis缓存JSONkey是item:1001value是商品VO过期时间30分钟✅ 面试官基础正确。但如果黑客用脚本狂刷item:-1、item:9999999这种不存在的商品ID呢谢飞机愣住…Redis里没这个key就查DBDB压力大…✅ 面试官这就是缓存穿透。解决方案谢飞机布隆过滤器…我…背过名字✅ 面试官Bloom Filter可拦截99%无效请求。但还有个问题——热门商品item:1001缓存过期瞬间大量请求同时打穿Redis直达DB怎么办谢飞机抓耳挠腮…加随机过期时间✅ 面试官对叫缓存击穿防护给热点key设置永不过期 后台异步刷新或用Redis分布式锁如SET key value EX 30 NX首个请求加载DB并回填其余等待。最后问如果Redis集群某节点宕机秒杀服务直接报错谢飞机叹气…应该…有降级熔断✅ 面试官正是用Resilience4j配置fallback缓存不可用时降级为本地Caffeine缓存 简化版商品信息仅名称价格保证核心链路可用。 面试尾声面试官合上笔记本推了推眼镜“谢同学你对Spring Boot和基础中间件有实操感也意识到分布式问题的存在——这是工程师成长的关键起点。但秒杀不是‘功能实现’而是业务、性能、容错、监控的系统工程。回去把Kafka分区策略、Redis布隆过滤器实现、Resilience4j fallback写个Demo下周HR联系你二面。”起身握手 “祝你——下次别擦椅子了我们等你带方案来。”✅ 附技术点详解小白友好版 场景定位电商秒杀业务特征瞬时超高并发万人抢100件、强一致性要求库存不能超卖、弱实时性订单可异步生成技术目标削峰抗流量、保一致不超卖、高可用故障降级 Spring Boot快速构建Web入口RestControllerValid做参数校验拦截非法请求Async或事件驱动ApplicationEvent解耦主流程但生产慎用默认线程池需自定义大小拒绝策略 Kafka可靠有序的消息管道分区键key userId→ 同用户请求路由到同一partition → 保证处理顺序 → 避免因乱序导致库存误判acksall min.insync.replicas2→ 强一致性写入防止消息丢失消费者手动提交offset→ 处理成功后再commit避免重复消费 Redis多维度缓存防护体系| 问题类型 | 现象 | 解决方案 | 关键代码/配置 | |----------|------|-----------|----------------| |缓存穿透| 查不存在key击穿DB | 布隆过滤器BloomFilter预判 | Guava BloomFilter or RedisBloom module | |缓存击穿| 热点key过期瞬时并发击穿 | 逻辑过期 分布式锁 |SET item:1001 json EX 300000 NX| |缓存雪崩| 大量key同一时间过期 | 随机TTL 多级缓存本地Caffeine |redisTemplate.expire(key, 30 random(10), TimeUnit.MINUTES)| 分布式锁进阶提醒❌synchronized/ReentrantLock仅限单JVM集群失效❌SETNX裸用无自动续期易死锁✅ 推荐RedissonRLock.lock(30, TimeUnit.SECONDS)→ 自动看门狗续期 可重入 公平锁支持 监控兜底Micrometer Prometheus暴露/actuator/metrics端点监控cache.hit.ratio、kafka.consumer.fetch-rate、jvm.memory.used等指标Grafana看板告警当Redis命中率95%或Kafka积压1w立即触发运维介入 学习建议不要死记命令在本地用Docker跑起Spring Boot Kafka Redis三件套模拟秒杀压测JMeter观察日志与监控变化——问题永远在现场不在八股文里。 文章标签Java面试,Spring Boot,Kafka,Redis,电商秒杀,分布式系统 作者提示谢飞机真实存在IDxiefeiji_2023已入职某电商中台组现正学习JVM调优…