Java大厂面试实录：Spring Cloud微服务+Redis缓存+Kafka消息队列实战问答

前言

本文记录了一场互联网大厂的Java技术面试，面试官严肃专业，候选人谢飞机（花名）水平参差不齐。通过3轮技术问答，涵盖微服务、缓存、消息队列等核心知识点，最后附带详细答案解析，帮助求职者系统学习。

---

面试场景：电商交易平台技术岗

面试官：请坐，我是今天的技术面试官。看你简历上写了3年Java经验，主要做电商方向？

谢飞机：对的领导，我主要负责电商平台的订单和支付模块，天天跟钱打交道，不敢出错啊！

面试官：好，那我们开始第一轮技术问答。

---

第一轮：基础架构与微服务

面试官：问题1：你们的电商系统用的是什么微服务架构？Spring Cloud哪些组件？

谢飞机：这个我熟！我们用的是Spring Cloud Alibaba，Nacos做注册中心和配置中心，Gateway做网关，Sentinel做限流熔断，Feign做服务调用，Se分布式事务...（越说越顺）

面试官：不错，基础组件都说到了。问题2：服务间调用如何保证可靠性？

谢飞机：我们加了重试机制，用Resilience4j做熔断降级，超时设置3秒，失败3次就熔断，半小时后自动恢复...这个我们生产环境验证过的。

面试官：很好，有生产经验。问题3：微服务链路追踪怎么做的？

谢飞机：呃...这个...我们好像用了...SkyWalking？还是Zipkin？反正就是那个能看调用链的，具体配置我得回去查查文档...

面试官：（微笑）没事，问题4：数据库连接池用的什么？为什么选它？

谢飞机：HikariCP！性能最好，启动快，连接复用率高，Spring Boot 2.x默认就是它。我们压测过，比C3P0和Druid都稳。

面试官：问题5：服务发现机制了解吗？Nacos和Eureka有什么区别？

谢飞机：Nacos支持AP和CP模式切换，Eureka只支持AP...Nacos还能做配置中心...具体原理我得想想...

---

第二轮：缓存与高并发

面试官：第一轮基础不错，我们进入第二轮，聊聊缓存和高并发。

问题1：你们的Redis缓存架构怎么设计的？

谢飞机：我们用的是Redis Cluster，3主3从，前端加了一层Caffeine本地缓存，热点数据先走本地，本地没有再走Redis，减少网络开销。

面试官：很好，多级缓存思路正确。问题2：缓存穿透、击穿、雪崩怎么解决？

谢飞机：穿透用布隆过滤器+空值缓存，击穿用互斥锁，雪崩给过期时间加随机值...这些我们都有预案。

面试官：问题3：Redis和数据库一致性怎么保证？

谢飞机：我们用的是...先更新数据库再删缓存...不对，好像是先删缓存再更新？哎呀这个我们用的是Canal监听binlog异步更新缓存...

面试官：（点头）Canal方案可以。问题4：秒杀场景怎么设计？

谢飞机：这个我熟！前端限流，Redis预减库存，Kafka异步下单，数据库最终扣减，超卖用乐观锁...我们去年双11扛住了10万QPS！

面试官：不错，有实战经验。问题5：分布式锁怎么实现？

谢飞机：Redis的setnx...不对，现在用Redisson的RLock，支持看门狗自动续期，比RedLock靠谱...

---

第三轮：消息队列与系统整合

面试官：最后一轮，聊聊消息队列和系统整合。

问题1：为什么选Kafka而不是RabbitMQ？

谢飞机：Kafka吞吐量大，适合日志和订单流水这种高吞吐场景，RabbitMQ适合复杂路由...我们订单用Kafka，通知用RabbitMQ，各取所长。

面试官：合理。问题2：消息丢失怎么防止？

谢飞机：生产者ack=all，消费者手动ack，Broker多副本...我们配置了幂等消费，重复消息也能处理。

面试官：问题3：消息积压怎么处理？

谢飞机：这个...我们加消费者？扩容？具体方案我得回去跟架构师确认一下...

面试官：问题4：分布式事务怎么做的？

谢飞机：核心交易用Seata的AT模式，非核心用最终一致性，通过Kafka+本地消息表...这个我们踩过坑，有完整方案。

面试官：问题5：系统监控怎么做的？

谢飞机：Prometheus+Grafana，业务指标自己埋点，JVM监控用Micrometer，链路追踪...这个刚才说了忘了...

---

面试结束

面试官：好的，今天面试就到这里。你基础不错，有些问题需要再深入。我们HR会在3个工作日内通知你结果，回去等消息吧。

谢飞机：好的领导，感谢给机会！不管结果如何都学到了很多东西！

---

答案解析与技术详解

第一轮答案详解

1. Spring Cloud核心组件

服务注册发现：Nacos/Eureka
服务网关：Spring Cloud Gateway
服务调用：OpenFeign
负载均衡：Spring Cloud LoadBalancer
熔断降级：Sentinel/Resilience4j
配置中心：Nacos/Spring Cloud Config
分布式事务：Seata
链路追踪：Sleuth+Zipkin/SkyWalking

业务场景：电商订单系统需要多个微服务协同，订单服务、库存服务、支付服务、物流服务需要高效通信。

2. 服务调用可靠性保障

• 重试机制：@Retryable注解，配置重试次数和间隔
• 熔断降级：Resilience4j的CircuitBreaker，失败阈值50%
• 超时控制：Feign配置connectTimeout和readTimeout
• 降级策略：返回默认值或缓存数据

3. 链路追踪方案

SkyWalking：无侵入，Agent方式
Zipkin：需要代码埋点
Jaeger：适合Go生态

技术要点：TraceID贯穿整个调用链，Span记录每个节点耗时

4. 数据库连接池对比

| 连接池 | 特点 | 适用场景 | |--------|------|----------| | HikariCP | 性能最优，轻量 | Spring Boot默认 | | Druid | 监控完善，阿里出品 | 需要详细监控 | | C3P0 | 老牌，稳定 | 遗留系统 |

5. Nacos vs Eureka

Nacos优势：
- 支持AP和CP模式
- 集成配置中心
- 支持多 namespace
- 服务健康检查更灵活

Eureka：
- 仅AP模式
- 需要单独配置中心
- 2.x已停止更新

第二轮答案详解

1. Redis多级缓存架构

请求 → Caffeine本地缓存 → Redis集群 → 数据库
       (1ms)           (5ms)      (50ms)

业务场景：商品详情页QPS高，本地缓存减少90%的Redis请求

2. 缓存三大问题解决方案

| 问题 | 原因 | 解决方案 | |------|------|----------| | 穿透 | 查询不存在数据 | 布隆过滤器+空值缓存 | | 击穿 | 热点key过期 | 互斥锁+永不过期 | | 雪崩 | 大量key同时过期 | 过期时间随机化 |

3. 缓存一致性方案对比

方案1：先删缓存再更新DB（推荐）
方案2：先更新DB再删缓存
方案3：Canal监听binlog异步更新
方案4：延迟双删

最佳实践：核心业务用Canal，非核心用延迟双删

4. 秒杀系统设计

1. 前端：按钮防重复，CDN静态资源
2. 网关：限流，IP黑名单
3. 缓存：Redis预减库存
4. 队列：Kafka异步下单
5. 数据库：乐观锁扣减
6. 兜底：服务降级

5. 分布式锁实现

// Redisson实现
RLock lock = redisson.getLock("order:123");
try {
    lock.lock();
    // 业务逻辑
} finally {
    lock.unlock();
}

技术要点：看门狗机制自动续期，避免死锁

第三轮答案详解

1. Kafka vs RabbitMQ选型

| 特性 | Kafka | RabbitMQ | |------|-------|----------| | 吞吐量 | 10万+/s | 1万+/s | | 延迟 | 毫秒级 | 微秒级 | | 可靠性 | 高 | 极高 | | 适用场景 | 日志、流水 | 通知、任务 |

2. 消息防丢失三保证

生产者：ack=all，重试机制
Broker：多副本，ISR机制
消费者：手动ack，幂等处理

3. 消息积压处理方案

1. 临时扩容消费者
2. 新建Topic分流
3. 优化消费逻辑
4. 排查异常消息

4. 分布式事务方案

Seata AT：无侵入，适合核心交易
本地消息表：最终一致性，适合非核心
TCC：高性能，需要业务改造
Saga：长事务，适合复杂流程

5. 监控体系搭建

指标采集：Prometheus+Micrometer
可视化：Grafana
日志：ELK Stack
链路：SkyWalking
告警：AlertManager

---

总结

本次面试覆盖了Java大厂核心技术栈，包括：

• 微服务：Spring Cloud Alibaba全家桶
• 缓存：Redis多级缓存+一致性方案
• 消息队列：Kafka高吞吐场景应用
• 分布式：事务、锁、链路追踪

学习建议：

1. 理解原理比死记硬背更重要
2. 结合业务场景思考技术方案
3. 生产经验是最大加分项
4. 不会的问题诚实回答，展示学习意愿

祝各位求职者面试顺利，拿到心仪的Offer！

---

本文仅供参考，实际面试请以具体公司要求为准