互联网大厂Java面试深度解析：从音视频场景到高并发微服务架构

面试官：欢迎来面我们音视频中台团队的Java高级工程师岗位。今天我们不聊八股，直接切入我们正在重构的「实时弹幕与智能推荐」系统。请带着工程思维和线上问题意识来思考。

第一轮：基础建模与高吞吐写入（考察JVM、Spring Boot、Kafka）

1. 弹幕消息峰值可达50万QPS，单条消息含用户ID、房间ID、内容、时间戳、设备指纹。你如何设计消息体序列化格式？为什么选Protobuf而非JSON？JVM层面如何避免GC压力？
2. 我们用Spring Boot 3.2 + Kafka 3.6构建弹幕接入网关。若Kafka Producer出现TimeoutException，除了重试，你还会在应用层做哪些熔断与降级预案？请结合Resilience4j给出代码片段。
3. 弹幕需严格按时间戳排序消费，但Kafka分区内部有序、全局无序。若业务要求“同房间弹幕绝对有序”，你如何设计Topic分区策略与消费者组协调机制？

第二轮：状态管理与低延迟读取（考察Redis、Caffeine、Spring Data JDBC）

4. 热门直播间（如TOP100）的弹幕需支持毫秒级历史回溯（最近100条）。我们已用Redis Stream存全量，但发现XRANGE在百万级Stream中延迟飙升。你如何用Redis Sorted Set + Caffeine本地缓存构建二级索引？请画出数据流向图并给出@Cacheable与@EventListener联动的伪代码。
5. 用户等级勋章（青铜→王者）影响弹幕展示特效。该状态变更频率低但读多写少，且需与MySQL用户表强一致。你如何用Spring Data JDBC的@Modifying + @Query实现“更新MySQL后自动失效Redis缓存”，并保证分布式环境下不穿透缓存？

第三轮：弹性容灾与可观测性（考察Micrometer、Prometheus、Jaeger）

6. 当CDN节点异常导致某区域用户弹幕延迟突增，监控大盘仅显示p99 > 2s。你如何用Micrometer自定义Timer埋点，在Spring WebFlux中区分“接入网关延迟”、“Kafka写入延迟”、“Redis读取延迟”，并在Prometheus中建立多维下钻看板？
7. 某次发布后，Jaeger链路追踪发现/api/v1/danmaku接口的processDanmaku()方法出现大量java.lang.OutOfMemoryError: Metaspace。请分析JVM参数-XX:MaxMetaspaceSize与Spring Boot热部署（DevTools）、Lombok注解处理器的关联，并给出线上环境安全的调优方案。

面试官合上笔记本，微笑道：

“今天的问题就到这里。你的方案里提到的Kafka分区键哈希冲突规避、Caffeine的refreshAfterWrite与expireAfterAccess组合策略，都很有实战价值。HR稍后会联系你，我们期待与你共事。”

附：核心代码实现与原理详解（小白可学）

Q1答案：Protobuf序列化 + JVM GC优化

// 使用protobuf生成的Message类（需protoc编译）
public class DanmakuProto {
  // 自动生成getters/setters，无反射开销
}

// JVM启动参数（关键！）
// -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 
// -XX:+UseStringDeduplication -XX:MetaspaceSize=512m
// 原理：Protobuf二进制体积比JSON小60%，避免Jackson反射+字符串拼接；G1GC保障停顿可控

Q2答案：Resilience4j熔断Producer

@Bean
public CircuitBreaker circuitBreaker() {
    return CircuitBreaker.ofDefaults("kafka-producer");
}

// 在Service中注入并使用
public void sendDanmaku(DanmakuProto msg) {
    Try.run(() -> kafkaTemplate.send("danmaku-topic", msg))
       .onFailure(throwable -> {
           if (throwable instanceof TimeoutException) {
               // 降级：写入本地RocketMQ备用队列或磁盘队列
               localQueue.offer(msg);
           }
       });
}

Q4答案：Redis Sorted Set + Caffeine二级索引

// Redis存储：ZADD room:{roomId} {timestamp} {danmakuId}
// Caffeine缓存：key=roomId, value=List<Danmaku>
@Cacheable(value = "danmakuHistory", key = "#roomId")
public List<Danmaku> getRecentDanmaku(String roomId) {
    // 先查Caffeine，未命中再查Redis Stream + Sorted Set
    return redisTemplate.opsForZSet().reverseRange("room:" + roomId, 0, 99);
}

// 缓存更新监听（监听MySQL binlog或Spring事件）
@EventListener
public void handleDanmakuUpdate(DanmakuUpdatedEvent event) {
    cache.asMap().remove(event.getRoomId()); // 主动失效
}

Q7答案：Metaspace OOM根因分析

根本原因：Spring Boot DevTools在开发环境启用restart机制，频繁加载/卸载ClassLoader；Lombok的@Data等注解在编译期生成大量字节码类，导致Metaspace持续增长。线上必须关闭DevTools！

安全方案：

# 生产JVM参数（禁用DevTools + 合理Metaspace）
-XX:MaxMetaspaceSize=1g -XX:MetaspaceSize=512m -Dspring.devtools.restart.enabled=false

延伸建议：用jstat -gc <pid>监控Metaspace使用率，结合Prometheus告警阈值设为80%。

结语：大厂面试的本质是“用技术解决不确定的业务问题”。本文所有问题均来自真实音视频中台故障复盘。掌握Protobuf序列化、Resilience4j熔断、Redis+本地缓存、JVM生产调优四大能力，你已超越80%的候选人。代码已开源至GitHub：[github.com/xxx/danmaku-arch]