互联网大厂Java面试实录：从音视频缓存到分布式事务

面试场景

面试官：你好，谢飞机同学，欢迎来参加我们公司的Java开发工程师面试。我看你的简历上写着有音视频处理和电商系统开发经验，今天我们来聊聊相关的技术问题。

谢飞机：（紧张地搓着手）好的好的，面试官您好！我准备好了！

第一轮：缓存与性能优化

面试官：首先，假设我们有一个音视频内容平台，用户量很大，每天有数百万的视频播放请求。你会如何设计缓存策略来减轻数据库压力？

谢飞机：这个简单！我会用Redis做缓存，把热门视频的元数据缓存起来，设置个过期时间，比如30分钟。这样就不用每次都查数据库了！

面试官：不错，思路很清晰。那如果遇到缓存穿透问题，比如有人恶意请求不存在的视频ID，导致大量请求直接打到数据库，你怎么解决？

谢飞机：嗯...这个...我会...用布隆过滤器！对，就是那个可以快速判断元素是否存在的数据结构。把所有存在的视频ID都放到布隆过滤器里，请求先过一遍过滤器，不存在的就直接返回，不会打到数据库。

面试官：很好！看来你对缓存问题有深入思考。那缓存雪崩呢？如果大量缓存同时过期，导致瞬间大量请求打到数据库，有什么解决方案？

谢飞机：这个...我会给缓存设置随机的过期时间，比如基础时间30分钟，再加上0-10分钟的随机值。这样就不会同时过期了。还可以用多级缓存，比如本地缓存+Redis，即使Redis挂了还有本地缓存兜底。

面试官：回答得很全面！看来你在缓存方面确实有实战经验。

第二轮：微服务架构与消息队列

面试官：接下来，假设我们的音视频平台需要支持用户上传视频后的自动处理流程，包括转码、截图、审核、发布等步骤。你会如何设计这个异步处理架构？

谢飞机：我会用Kafka做消息队列！用户上传完成后，发送一个"video.uploaded"事件到Kafka，然后各个处理服务订阅这个主题，各自处理自己的任务。

面试官：很好。那如果某个处理步骤失败了，比如转码服务暂时不可用，你怎么保证消息不会丢失，并且能够重试？

谢飞机：这个...Kafka有持久化机制，消息会保存在磁盘上。消费者可以手动提交偏移量，处理成功了才提交，失败了就不提交，下次重启还能重新消费。还可以设置重试次数...

面试官：基本思路是对的。那如果不同的处理步骤有依赖关系，比如必须先转码完成才能进行审核，你怎么保证处理顺序？

谢飞机：呃...这个...我可以...用多个topic？转码完成后发一个"video.transcoded"事件，审核服务监听这个事件...这样就能保证顺序了。

面试官：嗯，这是个可行的方案。不过你有没有考虑过使用Saga模式或者状态机来管理这种复杂的业务流程？

谢飞机：（挠头）Saga模式...我听说过，但是具体怎么实现...不太清楚。

面试官：没关系，我们继续下一个问题。

第三轮：分布式事务与数据一致性

面试官：现在假设我们的平台要和第三方支付系统集成，用户购买会员服务时需要同时扣减用户余额和增加会员权益。这是一个典型的分布式事务场景，你会如何保证数据一致性？

谢飞机：我会用...两阶段提交？或者...消息队列的事务消息？

面试官：能详细说说事务消息的实现思路吗？

谢飞机：就是...先发一个预备消息，然后执行本地事务，如果本地事务成功了，就确认消息，否则就回滚...具体的实现细节我可能说得不太准确。

面试官：那你知道Seata框架吗？它提供了哪些分布式事务模式？

谢飞机：Seata...我知道是阿里开源的分布式事务框架，有AT模式、TCC模式...但是具体区别和适用场景我说不太清楚。

面试官：最后一个问题，在高并发场景下，如何避免重复支付的问题？

谢飞机：可以用幂等性设计！比如给每个支付请求生成唯一的请求ID，服务端记录已经处理过的请求ID，重复的就直接返回之前的结果。

面试官：不错，幂等性确实是解决这个问题的关键。今天的面试就到这里，你先回去等通知吧。

谢飞机：（松了一口气）谢谢面试官！

技术详解

缓存策略与问题解决

在高并发的音视频平台中，缓存是提升系统性能的关键组件。合理的缓存策略需要考虑以下几种常见问题：

1. 缓存穿透

• 问题：恶意请求不存在的数据，绕过缓存直接查询数据库
• 解决方案：
  • 布隆过滤器：将所有存在的数据哈希到bitmap中，快速判断key是否存在
  • 缓存空值：对于查询结果为空的key，也缓存一个空值，设置较短过期时间

2. 缓存雪崩

• 问题：大量缓存同时过期，导致数据库瞬间压力剧增
• 解决方案：
  • 随机过期时间：在基础过期时间上增加随机值
  • 多级缓存：本地缓存（Caffeine）+ 分布式缓存（Redis）
  • 熔断降级：当数据库压力过大时，返回默认值或降级数据

3. 缓存击穿

• 问题：热点key过期瞬间，大量请求同时查询数据库
• 解决方案：
  • 互斥锁：只有一个线程去加载数据，其他线程等待
  • 逻辑过期：不设置物理过期时间，后台异步更新

微服务异步处理架构

对于音视频处理这类耗时操作，异步处理架构是最佳选择：

// 视频上传事件
public class VideoUploadedEvent {
    private String videoId;
    private String userId;
    private String originalUrl;
    // getters and setters
}

// Kafka生产者
@Service
public class VideoEventProducer {
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;
    
    public void publishVideoUploaded(String videoId) {
        VideoUploadedEvent event = new VideoUploadedEvent();
        event.setVideoId(videoId);
        // ... 设置其他属性
        
        String message = JSON.toJSONString(event);
        kafkaTemplate.send("video-processing-topic", videoId, message);
    }
}

// 转码服务消费者
@Component
public class TranscodingConsumer {
    @KafkaListener(topics = "video-processing-topic")
    public void handleVideoUploaded(String message) {
        try {
            VideoUploadedEvent event = JSON.parseObject(message, VideoUploadedEvent.class);
            // 执行转码逻辑
            transcodingService.transcode(event.getVideoId());
            
            // 发送转码完成事件
            eventPublisher.publishVideoTranscoded(event.getVideoId());
        } catch (Exception e) {
            // 记录错误，根据业务需求决定是否重试
            log.error("Transcoding failed", e);
        }
    }
}

消息可靠性保证：

• 生产者：开启事务消息，确保本地事务和消息发送的原子性
• 消费者：手动提交偏移量，处理成功后才提交
• 监控：建立死信队列，处理多次重试失败的消息

分布式事务解决方案

1. 事务消息模式

• 适用于最终一致性场景
• 实现步骤：
  1. 发送预备消息到消息队列
  2. 执行本地事务
  3. 根据本地事务结果确认或取消消息
  4. 消费者处理消息，执行对应的业务逻辑

2. Seata框架模式

• AT模式：自动补偿模式，适合简单业务

  • 一阶段：业务数据和回滚日志记录在同一个本地事务中提交
  • 二阶段：提交异步删除日志；回滚通过日志进行反向补偿

• TCC模式：Try-Confirm-Cancel，适合复杂业务

  • Try：预留资源
  • Confirm：确认执行
  • Cancel：取消预留

3. 幂等性设计

• 为每个请求生成唯一ID（UUID或雪花算法）
• 服务端维护已处理请求ID的记录（Redis Set或数据库表）
• 处理请求前先检查是否已处理过

@Service
public class PaymentService {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    
    public PaymentResult processPayment(PaymentRequest request) {
        String requestId = request.getRequestId();
        
        // 检查是否已处理
        Boolean isProcessed = redisTemplate.opsForValue()
            .setIfAbsent("payment:" + requestId, "processed", Duration.ofHours(24));
            
        if (Boolean.FALSE.equals(isProcessed)) {
            // 已处理过，直接返回结果
            return getPreviousResult(requestId);
        }
        
        // 执行支付逻辑
        return executePayment(request);
    }
}

通过以上技术方案的合理组合，可以构建一个高性能、高可用、数据一致的音视频平台系统。