视频播放进度记录实现思路

视频播放的进度记录，需要实现视频续播功能。

首先，要做到切换设备后还能续播，用户的播放进度必须保存在服务端，而不是客户端。

其次，用户突然断开或者切换设备，续播的时间误差不能超过20秒，那播放进度的记录频率就需要比较高。前端每隔10秒就发起一次心跳请求，提交最新的播放进度，记录到服务端。这样用户下一次续播时直接读取服务端的播放进度，就可以将时间误差控制在10秒左右。

1. 功能背景

• 网站课程以录播视频为主，为提升学习体验，需要实现视频续播功能。

• 用户断开连接或切换设备后，仍然可以从上一次播放位置继续学习。

• 产品要求：

  • 续播时间误差控制在 20 秒以内。

  • 支持多设备切换续播。

2. 功能分析

• 服务端存储进度：

  • 为保证多设备同步，播放进度需要存储在服务端，而不是本地客户端。

  • 存储的播放进度包括：用户 ID、视频 ID 和当前播放时间点。

• 高频率记录：

  • 为控制误差在 20 秒以内，用户播放时需要频繁向服务端更新播放进度。

  • 前端每隔 10 秒通过心跳请求发送当前播放进度，减少误差范围。

• 多设备支持：

  • 用户切换设备时，前端从服务端获取最后一次记录的播放进度，并从该进度点开始播放。

3. 功能设计

3.1 前端设计

3.1.1 播放进度上传

• 前端在播放视频时，每隔 10秒通过心跳请求将当前播放进度（currentTime）发送到服务端。

• 如果用户暂停视频或页面关闭，也会发送一次停止时的进度。

3.1.2 播放进度恢复

• 用户打开新设备或重新加载页面时，通过 API 请求服务端获取当前用户和视频的最后一次记录的播放进度。

• 根据返回的时间点（currentTime），将视频定位到对应的时间点。

3.2 服务端设计

服务端主要负责存储、查询和更新用户的播放进度。

3.2.1 数据模型

设计一个数据库表，用于存储用户的播放进度信息：

CREATE TABLE video_progress (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,       -- 用户 ID
    video_id BIGINT NOT NULL,      -- 视频 ID
    progress INT NOT NULL,         -- 播放进度（单位：秒）
    update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- 更新时间
    UNIQUE(user_id, video_id)      -- 确保每个用户的每个视频只存储一条记录
);

3.2.2 功能实现

前端在播放视频时，每隔 10秒通过心跳请求将当前播放进度（currentTime）发送到服务端，服务端将数据写入数据库。

4. 问题分析

由于播放进度记录较为频繁，写数据库的压力太大。

写数据库压力大的问题将在下一篇，视频播放进度记录方案改进中解决。