Redis优化高并发视频播放进度记录方案

1. 项目背景与问题分析

在在线教育平台的视频播放场景中，播放进度记录是一个看似简单但实际复杂的功能。天机学堂最初采用的方案是前端每隔15秒向服务端发送一次心跳请求，记录当前播放进度。这种设计在用户量较小时表现尚可，但随着用户规模增长，系统开始暴露出严重的性能问题。

1.1 原有方案的技术实现

原方案的核心流程如下：

1. 前端播放器每隔15秒发送一次心跳请求，携带当前播放进度（moment）
2. 服务端接收到请求后执行以下数据库操作：
   • 查询该用户当前小节的播放记录是否存在
   • 不存在则新增记录，存在则更新播放进度
   • 判断进度是否首次超过50%，若是则标记小节为"已学完"
   • 更新课程表中最近学习的小节ID和学习时间
   • 更新已学小节数量，并判断课程是否全部学完

这个方案的主要问题在于：

• 每次心跳请求都会触发5-6次数据库操作
• 用户观看10分钟视频就会产生40次数据库写入
• 90%以上的进度更新都是中间状态，最终会被覆盖

1.2 性能瓶颈分析

通过压力测试和性能监控，我们发现系统瓶颈主要集中在：

1. 数据库IOPS过高：频繁的小数据量写入导致磁盘I/O队列堆积
2. 连接池耗尽：高并发时数据库连接成为稀缺资源
3. CPU利用率波动大：每次写入都触发索引更新和事务处理

特别是在热门课程上新时，大量用户同时观看视频会导致数据库响应时间从平时的10ms飙升到500ms以上，严重时甚至引发级联故障。

2. 优化方案设计与选型

2.1 高并发优化三大方向

面对高并发写入场景，我们主要考虑三个优化方向：

2.1.1 水平扩展方案

• 数据库读写分离：将读操作路由到从库
• 分库分表：按用户ID哈希分散写入压力
• 缺点：需要复杂的运维支持，无法减少总体写入量

2.1.2 服务保护方案

• 引入Sentinel实现限流降级
• 配置数据库连接池熔断策略
• 缺点：属于被动防御，不能提升系统吞吐量

2.1.3 单机性能优化

• 减少不必要的数据库操作
• 合并重复写入请求
• 优点：开发可控，效果立竿见影

2.2 写多读少场景优化手段

针对播放进度这种典型的写多读少场景，我们评估了三种优化手段：

2.3 方案选型决策

基于业务特点，我们最终选择了合并写入方案，因为：

1. 播放进度具有覆盖特性 - 只需要保留最后一次有效值
2. 中间状态数据可以丢弃 - 不需要保证100%的进度记录
3. 最终一致性可接受 - 短暂的数据延迟不影响用户体验

具体实现上，我们设计了两种技术方案：

1. Redis + 定时任务：定期批量同步缓存数据到数据库
2. Redis + 延迟任务：仅在用户停止播放时持久化最终进度

3. Redis + 定时任务方案实现

3.1 核心架构设计

该方案的核心思想是将高频的数据库写入转为先写Redis缓存，再通过定时任务批量同步到数据库。架构分为三层：

1. 接入层：接收前端心跳请求
2. 缓存层：Redis Hash结构存储最新进度
3. 持久层：定时任务批量同步到MySQL

3.2 Redis数据结构设计

我们采用Hash结构存储播放进度数据，设计如下：

java复制// Key设计
String key = "learning:record:hash:" + lessonId;

// Field设计
String field = sectionId.toString();

// Value设计
{
  "id": recordId,       // 记录ID
  "moment": 125,       // 播放进度(秒)
  "finished": false,   // 是否完成
  "finishTime": null   // 完成时间
}

这种设计的好处是：

• 按课程ID分Key，避免大Key问题
• 使用Hash结构，方便按小节查询和更新
• JSON序列化存储，扩展性强

3.3 关键代码实现

3.3.1 缓存工具类

java复制@Slf4j
@Component
@RequiredArgsConstructor
public class LearningRecordCacheHandler {
    private final StringRedisTemplate redisTemplate;
    
    private static final String CACHE_KEY_TEMPLATE = "learning:record:hash:{}";
    private static final Duration CACHE_EXPIRE_TIME = Duration.ofMinutes(30);

    // 写入缓存
    public void writeCache(Long lessonId, Long sectionId, LearningRecord record) {
        try {
            String key = buildCacheKey(lessonId);
            String hashValue = JsonUtils.toJsonStr(new CacheData(record));
            redisTemplate.opsForHash().put(key, sectionId.toString(), hashValue);
            redisTemplate.expire(key, CACHE_EXPIRE_TIME);
        } catch (Exception e) {
            log.error("写入学习记录缓存失败", e);
        }
    }
    
    // 读取缓存
    public CacheData readCache(Long lessonId, Long sectionId) {
        try {
            String key = buildCacheKey(lessonId);
            Object value = redisTemplate.opsForHash().get(key, sectionId.toString());
            if (value == null) return null;
            return parseCacheData(value.toString());
        } catch (Exception e) {
            log.error("读取学习记录缓存失败", e);
            return null;
        }
    }
}

3.3.2 业务逻辑改造

java复制@Slf4j
@Service
public class RedisLearningRecordServiceImpl implements ILearningRecordService {
    
    public void addLearningRecord(LearningRecordFormDTO dto) {
        // 1. 优先查询Redis缓存
        CacheData cacheData = cacheHandler.readCache(dto.getLessonId(), dto.getSectionId());
        
        // 2. 判断是否首次学完
        boolean isFirstFinished = isFirstFinished(dto, cacheData);
        
        // 3. 获取或创建学习记录
        LearningRecord record = getRecordFromCacheOrDb(dto, cacheData);
        
        // 4. 写入Redis缓存
        cacheHandler.writeCache(dto.getLessonId(), dto.getSectionId(), record);
    }
}

3.3.3 定时任务配置

java复制@Scheduled(fixedRate = 60000) // 每分钟执行一次
public void syncRecordsToDatabase() {
    // 1. 扫描所有课程Key
    Set<String> keys = redisTemplate.keys("learning:record:hash:*");
    
    // 2. 批量处理每个课程的记录
    for (String key : keys) {
        Map<Object, Object> entries = redisTemplate.opsForHash().entries(key);
        List<LearningRecord> records = convertToRecords(entries);
        
        // 3. 批量更新数据库
        batchUpdate(records);
        
        // 4. 清理已处理的数据
        redisTemplate.delete(key);
    }
}

3.4 方案优缺点分析

优点：

1. 数据库写入次数减少90%以上
2. 响应时间从50ms降低到10ms以内
3. 实现相对简单，改造成本低

缺点：

1. Redis宕机可能导致数据丢失
2. 定时任务间隔期间数据未持久化
3. 批量写入时可能产生短时数据库压力

实际测试数据显示：在1000并发用户场景下，数据库QPS从2000+降到200左右，CPU利用率从80%降到30%

4. Redis + 延迟任务方案实现

4.1 核心设计思想

该方案的核心创新点是"惰性持久化"策略：

• 用户播放时：只更新Redis缓存
• 用户停止播放后：延迟20秒确认无新进度后，才持久化到数据库

这种设计完美契合播放进度业务的特性：

1. 只有最后一次进度值有意义
2. 不需要记录中间过程
3. 短暂延迟不影响用户体验

4.2 延迟任务实现方案对比

我们评估了四种延迟任务实现方式：

最终选择DelayQueue因为：

1. 延迟时间短（20秒）
2. 不需要分布式支持
3. 无外部依赖，性能高

4.3 关键技术实现

4.3.1 延迟任务核心类

java复制@Data
public class DelayTask<D> implements Delayed {
    private D data;
    private long deadlineNanos; // 到期时间戳
    
    @Override
    public long getDelay(TimeUnit unit) {
        return unit.convert(deadlineNanos - System.nanoTime(), NANOSECONDS);
    }
    
    @Override
    public int compareTo(Delayed o) {
        return Long.compare(getDelay(NANOSECONDS), o.getDelay(NANOSECONDS));
    }
}

4.3.2 延迟任务处理器

java复制@Slf4j
@Component
public class LearningRecordDelayTaskHandler {
    private final DelayQueue<DelayTask<RecordTaskData>> queue = new DelayQueue<>();
    
    @PostConstruct
    public void init() {
        CompletableFuture.runAsync(this::handleDelayTask);
    }
    
    private void handleDelayTask() {
        while (true) {
            try {
                DelayTask<RecordTaskData> task = queue.take();
                RecordTaskData data = task.getData();
                
                // 检查Redis中的当前进度
                LearningRecord current = readRecordCache(data.getLessonId(), data.getSectionId());
                if (current == null || !data.getMoment().equals(current.getMoment())) {
                    continue; // 进度已更新，放弃本次任务
                }
                
                // 持久化到数据库
                persistRecord(current);
            } catch (Exception e) {
                log.error("处理延迟任务异常", e);
            }
        }
    }
}

4.3.3 业务逻辑整合

java复制public void addLearningRecord(LearningRecordFormDTO dto) {
    // 1. 更新Redis缓存
    LearningRecord record = updateCache(dto);
    
    // 2. 提交延迟任务
    delayTaskHandler.addTask(new RecordTaskData(
        record.getLessonId(),
        record.getSectionId(),
        record.getMoment()
    ));
    
    // 3. 处理学完状态
    if (isFirstFinished(dto)) {
        markAsFinished(record);
    }
}

4.4 方案优化效果

性能提升：

• 数据库写入次数减少99%以上
• 平均响应时间<5ms
• 支持5000+并发用户

资源节省：

• 数据库CPU利用率降低60%
• 连接池使用率从90%降到20%
• Redis内存占用<100MB

5. 方案对比与选型建议

5.1 两种方案对比

5.2 选型建议

1. 教育类长视频平台：推荐延迟任务方案

   • 单次观看时间长（30分钟+）
   • 用户会反复暂停/继续
   • 需要准确记录学习完成时间

2. 短视频学习平台：推荐定时任务方案

   • 单视频时长短（<5分钟）
   • 用户连续观看多个视频
   • 对实时性要求不高

3. 混合型平台：可以两种方案结合

   • 核心课程使用延迟任务
   • 普通内容使用定时任务

6. 生产环境注意事项

6.1 Redis高可用配置

必须配置Redis哨兵或集群模式，避免单点故障导致数据丢失：

yaml复制spring:
  redis:
    sentinel:
      master: mymaster
      nodes: 192.168.1.1:26379,192.168.1.2:26379

6.2 异常处理机制

需要完善以下异常处理场景：

1. Redis连接超时：降级为直接写数据库
2. 数据库写入失败：记录日志并告警
3. 延迟任务堆积：监控队列长度并报警

6.3 监控指标

关键监控指标包括：

1. Redis缓存命中率
2. 延迟任务队列积压量
3. 数据库写入延迟
4. 定时任务执行耗时

7. 扩展优化思路

7.1 二级缓存优化

对于超大规模用户，可以引入本地缓存+Redis的多级缓存：

1. 优先读取本地Guava Cache
2. 未命中再查询Redis
3. 最后回源数据库

7.2 智能延迟策略

根据用户行为动态调整延迟时间：

1. 活跃用户：缩短延迟时间（10秒）
2. 非活跃用户：延长延迟时间（60秒）
3. 完课用户：立即持久化

7.3 离线计算补偿

通过离线作业补偿丢失的数据：

1. 分析播放日志中的进度记录
2. 对比数据库中的最终记录
3. 补录关键进度节点

在实际项目中，我们最终采用了Redis+延迟任务的方案，经过3个月的生产环境验证，系统在日均100万用户访问量下保持稳定，数据库负载降低80%以上。这个方案特别适合对数据实时性要求较高且用户观看时长较长的在线教育场景。