Java大厂面试实录：面试官vs谢飞机的微服务攻防战

开场白

某互联网大厂会议室，面试官坐在对面，谢飞机紧张地搓着手。

面试官："谢飞机是吧？看你简历写精通微服务架构，今天咱们聊聊实际业务场景。"

谢飞机："好的好的，您请问！"

---

第一轮：电商场景下的服务治理

面试官："假设你在做电商平台，大促期间流量激增，如何保证系统稳定？"

谢飞机："这个我会！用限流、熔断、降级三板斧，Spring Cloud Alibaba的Sentinel就能搞定！"

面试官："不错，那服务之间调用超时怎么处理？"

谢飞机："配置超时时间，加上重试机制...大概这样？"

面试官："具体用哪个组件？重试策略有哪些？"

谢飞机："呃...Resilience4j？还是Hystrix？反正有个圈圈图标的那个..."

面试官："那服务发现用什么？"

谢飞机："Nacos！这个我熟，注册中心嘛，服务上下线都能感知！"

面试官："嗯，基础还可以，继续。"

---

第二轮：高并发下的缓存与消息队列

面试官："电商秒杀场景，库存怎么扣减？"

谢飞机："Redis预减库存！先扣Redis，再异步写数据库！"

面试官："那Redis挂了怎么办？"

谢飞机："呃...有集群？主从？哨兵？反正不会全挂吧..."

面试官："缓存穿透、击穿、雪崩怎么区分和解决？"

谢飞机："穿透是查不存在的数据，加布隆过滤器；击穿是热点key过期，加互斥锁；雪崩是大面积过期，随机过期时间...大概这样？"

面试官："消息队列选Kafka还是RabbitMQ？为什么？"

谢飞机："Kafka吞吐量大，适合日志；RabbitMQ延迟低，适合业务消息...看场景选嘛！"

面试官："消息重复消费怎么处理？"

谢飞机："幂等性！数据库唯一键或者Redis记录消息ID...应该吧？"

---

第三轮：分布式事务与监控

面试官："微服务架构下，订单创建涉及多个服务，如何保证数据一致性？"

谢飞机："分布式事务！Seata的AT模式...或者TCC？"

面试官："AT和TCC的区别是什么？"

谢飞机："AT是自动的，TCC要手动写...具体区别我回去查查文档..."

面试官："线上问题怎么排查？"

谢飞机："看日志！ELK Stack！还有Prometheus+Grafana监控！"

面试官："链路追踪用什么？"

谢飞机："SkyWalking？Zipkin？Jaeger？反正有个追踪链的图..."

面试官："JVM调优做过吗？"

谢飞机："调过...-Xms -Xmx...GC日志分析...具体参数我得想想..."

---

面试结束

面试官："好了，今天先到这里。你回去等通知吧，HR会联系你。"

谢飞机："好的好的，谢谢面试官！"

（谢飞机出门后长舒一口气："应该能过吧？反正该说的都说了...")

---

面试题详细解析

第一轮答案：服务治理

1. 大促流量激增如何保证系统稳定？

技术方案：

• 限流：使用Sentinel或Resilience4j配置QPS限流，保护核心服务
• 熔断：当错误率达到阈值时自动熔断，避免雪崩
• 降级：非核心功能降级，保证核心链路可用
• 扩容：提前预案，K8s自动扩缩容

业务场景： 双11、618等大促期间，流量可能是平时10倍以上，必须提前压测和预案。

2. 服务调用超时处理

技术方案：

• 使用OpenFeign配置超时时间：connectTimeout和readTimeout
• 重试策略：使用Spring Retry或Resilience4j Retry
• 重试条件：仅对幂等接口重试，POST请求谨慎重试

代码示例：

feign:
  client:
    config:
      default:
        connectTimeout: 5000
        readTimeout: 5000

3. 服务发现组件

技术方案：

• Nacos：阿里开源，支持注册中心和配置中心
• Consul：HashiCorp出品，支持多数据中心
• Eureka：Netflix开源，已停止更新

推荐： 新项目首选Nacos，功能完善且社区活跃。

---

第二轮答案：缓存与消息队列

1. 秒杀库存扣减方案

技术方案：

// Redis预减库存
String key = "stock:" + productId;
Long stock = redisTemplate.opsForValue().decrement(key);
if (stock >= 0) {
    // 发送消息到Kafka异步扣减数据库
    kafkaTemplate.send("order-topic", orderId);
} else {
    // 库存不足
    redisTemplate.opsForValue().increment(key);
}

注意点：

• Redis使用Lua脚本保证原子性
• 数据库最终一致性校验
• 防止超卖：数据库加乐观锁

2. Redis高可用方案

| 方案 | 说明 | 适用场景 | |------|------|----------| | 主从复制 | 一主多从，读写分离 | 读多写少 | | 哨兵模式 | 自动故障转移 | 中小规模 | | Cluster集群 | 分片存储，高可用 | 大规模生产 |

3. 缓存三大问题

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

4. Kafka vs RabbitMQ

| 特性 | Kafka | RabbitMQ | |------|-------|----------| | 吞吐量 | 非常高(10万+/s) | 中等(1万+/s) | | 延迟 | 毫秒级 | 微秒级 | | 可靠性 | 至少一次 | 恰好一次 | | 适用场景 | 日志、大数据 | 业务消息、事务 |

5. 消息幂等性处理

方案：

• 数据库唯一约束
• Redis记录已消费消息ID
• 状态机控制（如订单状态只能单向流转）

---

第三轮答案：分布式事务与监控

1. 分布式事务方案对比

| 模式 | 说明 | 优点 | 缺点 | |------|------|------|------| | AT | 自动两阶段提交 | 无侵入 | 性能损耗 | | TCC | Try-Confirm-Cancel | 性能好 | 开发成本高 | | Saga | 长事务补偿 | 适合长流程 | 补偿逻辑复杂 | | 本地消息表 | 最终一致性 | 简单可靠 | 有延迟 |

2. 链路追踪

主流方案：

• SkyWalking：国产，APM功能完善
• Jaeger：Uber开源，云原生友好
• Zipkin：Spring Cloud集成方便

核心概念： TraceID贯穿整个调用链，Span记录每个服务耗时。

3. JVM调优核心参数

# 堆内存
-Xms4g -Xmx4g

# 新生代
-Xmn2g

# GC算法
-XX:+UseG1GC

# GC日志
-XX:+PrintGCDetails -Xloggc:/var/log/gc.log

# OOM dump
-XX:+HeapDumpOnOutOfMemoryError

---

学习建议

1. 基础扎实：Java核心、JVM、并发编程必须熟练
2. 框架原理：Spring Boot自动配置、Spring Cloud组件原理
3. 实战经验：参与真实项目，积累问题排查经验
4. 持续学习：关注技术社区，保持技术敏感度

---

结语： 面试是双向选择，技术是硬实力，表达是软实力。祝各位求职者都能拿到心仪的Offer！

（本文纯属虚构，如有雷同，纯属巧合）