如何最优存储剧集观看时长？高并发场景下数据库性能优化咨询

当前方案的风险 #

你的当前实现在千人同时观看的场景下必然会导致数据库故障：每秒4000次的写操作（查询+新增/更新）会快速耗尽数据库连接池，引发锁竞争（尤其是更新同一剧集的用户记录时），磁盘IO也会成为瓶颈，最终导致数据库响应变慢、超时甚至崩溃。

最优解决方案 #

1. 客户端延迟批量提交 #

• 取消每秒发送请求的逻辑，改为每10-30秒提交一次，或者在用户暂停剧集、切换集数、关闭页面时触发提交。
• 客户端本地缓存累计的观看时长，每次提交时把这段时间的增量同步到后端，大幅降低请求频率。比如单用户从每秒4次降到每20秒1次，千人并发下每秒请求数从4000降到50，压力直接减少98%。

2. 原子化SQL操作 #

把“查询是否存在+新增/更新”的两步操作合并为一次原子SQL：

• MySQL用INSERT INTO watch_history(user_id, episode_id, duration) VALUES(?, ?, ?) ON DUPLICATE KEY UPDATE duration = duration + ?
• PostgreSQL用INSERT INTO watch_history(user_id, episode_id, duration) VALUES(?, ?, ?) ON CONFLICT(user_id, episode_id) DO UPDATE SET duration = watch_history.duration + EXCLUDED.duration
  这样一次SQL就能完成原来两次操作，减少一半的数据库交互次数，同时避免并发下的竞态问题。

3. 引入缓存层削峰 #

用Redis作为中间缓存：

• 用户的观看时长先写入Redis（比如用哈希结构存储user:episode的时长），Redis能轻松扛住每秒数万次的写操作。
• 后端定时（比如每分钟）从Redis批量读取数据，同步到数据库。这样数据库只需要处理低频的批量写入，彻底避开高并发冲击。

4. 异步消息队列处理 #

如果必须保留较高的实时性，可以把更新请求放到消息队列（如Kafka、RabbitMQ）：

• 客户端发请求后，后端直接把消息丢进队列，快速返回响应，不用等待数据库操作完成。
• 消费端从队列中取出消息，异步处理数据库的新增/更新操作。消息队列能自动削峰，避免瞬间高并发打垮数据库。

5. 数据库基础优化 #

• 给user_id和episode_id添加联合唯一索引，既加速查询和原子操作，又避免重复记录。
• 调整数据库配置：增大连接池大小、优化InnoDB缓冲池、开启写入缓存等，提升数据库的并发处理能力。

总结 #

当前方案在高并发场景下完全不可行，必须通过「客户端降频+原子SQL+缓存/消息队列」的组合方案来优化，才能支撑千人甚至更高的并发量。

内容的提问来源于stack exchange，提问作者johnDoe220