Java面试官怒怼水货程序员：Spring Cloud微服务+Kafka消息队列+Redis缓存，你到底会不会？
面试场景：电商大促系统架构设计
面试官（严肃脸）：谢飞机，你好。今天我们聊聊你在电商大促场景下的技术选型和问题排查能力。
谢飞机（挠头笑）：哎呀，您问吧，我都会！
第一轮：基础框架与微服务治理
面试官：
- 你们项目用的 Spring Boot 版本是多少？为什么选择这个版本？
- 微服务之间怎么通信？用 OpenFeign 还是 gRPC？
- 服务注册发现用的是 Eureka 还是 Consul？为什么？
- 如果某个服务突然不可用，你怎么保证系统稳定性？
谢飞机：
- 嗯…我们用的是…2点几吧，因为…大家都用！
- 通信啊，用 HTTP 啊，Feign 吧，gRPC 太复杂了。
- 注册中心？哦，Eureka！Netflix 的嘛，很牛！
- 不可用？重启一下就好了！（小声）
面试官（皱眉）：…好吧，那我们深入一点。
第二轮：高并发与消息削峰
面试官：
- 大促时订单量激增，你怎么防止数据库被打垮？
- 为什么选择 Kafka 而不是 RabbitMQ？
- 消息重复消费怎么处理？
- 如何保证消息的顺序性？
谢飞机：
- 加 Redis 缓存！缓存扛不住就加机器！
- Kafka 快啊！听说比 RabbitMQ 快一百倍！
- 重复消费？前端加个防重按钮不就行了？
- 顺序性？Kafka 不是天然有序吗？（一脸自信）
面试官（扶额）：…你对 Kafka 的分区机制了解吗？
谢飞机：分区？是不是像硬盘分区那样？
第三轮：缓存与数据一致性
面试官：
- Redis 缓存和数据库如何保证一致性？
- 用的是哪种缓存策略？Cache-Aside 还是 Write-Through？
- 缓存穿透、击穿、雪崩分别是什么？怎么解决？
- 你们用 Caffeine 做本地缓存了吗？为什么？
谢飞机：
- 一致性？删了缓存再写数据库！
- 策略？我们用的是“先查缓存，没有就查库”！
- 穿透就是有人恶意攻击，加布隆过滤器！击穿就是热点 key 挂了，加互斥锁！雪崩就是 Redis 宕机，多搞几个集群！
- Caffeine？没听过，是不是咖啡因？提神用的？
面试官（叹气）：…好的，谢飞机同学，今天面试就到这里。你回去等通知吧。
谢飞机（起身握手）：谢谢面试官！我回去就学 Caffeine！
技术解析：电商大促系统核心架构
1. 微服务通信与治理
- Spring Boot 2.7/3.x：选择 LTS 版本确保长期支持，兼容 Spring Cloud 2022.x。
- OpenFeign + Resilience4j：声明式 HTTP 客户端，集成熔断、限流，避免级联失败。
- Consul 替代 Eureka：Consul 支持多数据中心、健康检查更灵活，适合云原生环境。
- Resilience4j：轻量级容错库，提供 CircuitBreaker、RateLimiter 等模式。
2. Kafka 消息队列设计
- 选型 Kafka：高吞吐（百万级 TPS）、持久化、分区并行，适合订单、日志等场景。
- 重复消费：业务层幂等设计（如订单状态机）、消息去重表（Redis SETNX）。
- 顺序性：单分区单消费者保证局部有序；全局有序需牺牲性能，一般不推荐。
3. 缓存与一致性方案
- Cache-Aside Pattern：先读缓存，miss 则读 DB 并回填；更新时先更新 DB 再删除缓存（延时双删防并发）。
- 缓存问题解决方案：
- 穿透：布隆过滤器拦截无效 ID + 空值缓存。
- 击穿：互斥锁（Redis SETNX）重建热点 key。
- 雪崩：随机过期时间 + 多级缓存（Caffeine + Redis）。
- Caffeine 本地缓存：减少 Redis 网络开销，适用于高频读、低变更数据（如商品类目）。
总结：电商大促系统需兼顾高并发、高可用、数据一致性。合理组合 Spring Cloud、Kafka、Redis、Caffeine 等技术栈，才能扛住流量洪峰。
)