直播转点播回看场景的并发模型，核心在于把“同时观看同一时刻”的直播压力，转化为“错峰访问不同时间点”的点播压力，用缓存分层加动态扩缩容来应对。
视频平台上线回看功能后，技术团队面对的第一道坎往往不是存储成本，而是并发模型怎么做，直播时用户集中涌入同一路流，回看时用户分散到不同时间点，但峰值压力反而更难预测有人拖进度条，有人倍速播放，有人只看最后五分钟的进球,下面直接拆解这个场景下的并发设计思路。
回看场景与直播并发的本质差异在哪里
做并发模型前，先搞清楚回看和直播的流量特征有什么不同，直播是同步强聚合，一万个用户看同一秒的画面，服务器只需要维护一份流数据分发给所有人，回看是异步弱聚合，一万个用户分散在一场两个小时的节目里，每个时间点可能只有几十人在看,但用户发起请求的瞬间是随机的。
更麻烦的是回看支持拖动进度条，直播的请求是线性的，回看的请求是跳跃式的，用户可以从第10分钟直接拖到第80分钟，这个动作会触发一次新的拉流请求，相当于在原本平稳的曲线上突然扎进一根尖刺，行业共识认为，回看场景的并发峰值往往出现在热门比赛或大结局播出之后的半小时内,大量用户同时回看同一个精彩片段。
另一个差异在于播放协议，直播多用HLS或HTTP-FLV，回看通常是MP4或DASH分片，HLS回看天然支持按时间段切片，但切片数量会随着时间增长，一个两小时的节目如果切成6秒一片，就有1200个分片，用户拖到任意位置，播放器只会请求最近的那个分片，这意味着同一时刻的热点分片可能非常集中。
构建回看并发模型的四个关键层
第一层：接入层的会话管理要能抗突发
用户点开回看，第一步是向后端请求播放地址，这个请求量级通常不大，但必须处理得快，接入层建议用无状态网关，把用户会话信息放在Redis或内存数据库里,避免粘滞会话导致单节点过载。
实际操作上，可以为回看接口单独设置限流阈值，直播的限流按路数算，回看的限流按请求次数算，比如一台前端机处理直播流时能扛住2000路并发，但处理回看地址请求时可能每秒只能处理2000个请求，因为每个请求都要做鉴权、时间戳校验、防盗链签名，如果发现某个IP在短时间内频繁请求不同分片的地址,直接返回验证码或降低优先级。
第二层：存储层要把冷热数据分开
回看视频的存储策略直接影响并发上限。热数据是刚结束直播后的一小段时间，比如昨天晚上的比赛，今天早上还有大量用户回看，这类数据要放在SSD或内存缓存里，最好靠近CDN边缘节点。温数据是最近一周的节目，放到对象存储加CDN回源。冷数据是一个月以前的，放到低成本存储,只在用户真正请求时才加载。
存储层的并发瓶颈在于回源，如果CDN没有命中，回源到对象存储时，对象存储的每秒请求数上限很容易被打满，解决方案是给回看服务单独建一层回源聚合队列，同一时刻相同分片的请求合并成一个，等数据回来后广播给所有等待的用户,这个操作能把回源压力降低一个数量级。
第三层：计算层的转码任务要削峰填谷
直播转点播通常需要实时录制并转码出多码率版本，但转码是CPU密集型操作，如果直播刚结束就立刻把所有码率转一遍，服务器会瞬间满负载，合理的做法是优先级区分：先转低码率标清版，因为大多数用户回看只是为了确认内容，不需要超清；隔半小时再转高清版,深夜再转超清版。
并发模型上，转码任务应该走消息队列，不要直接同步调用，队列积压时自动扩容转码Worker，但给每个Worker设置最大处理时间，超过30秒的任务强制中断并重试，这样即使遇到突发回看潮,也不会因为转码任务堆积导致整个服务雪崩。
调度策略：如何应对“同时回看同一片段”的突发
回看场景最常见的故障是某个精彩片段被大量用户同时拖动定位，比如足球比赛的进球瞬间，可能几千人同时把进度条拖到第75分钟，这种情况本质上是时间维度的热点。
应对方案是给播放器加一个关键帧对齐机制，播放器请求分片时，后端返回的不是精确秒点，而是最近的关键帧索引，这样用户虽然拖到了第75分30秒，实际播放的是第75分28秒的关键帧，多个用户落到同一个关键帧上,CDN的命中率会显著提升。
边缘节点需要针对回看场景做分片预取，当检测到某个分片的请求频率超过阈值，边缘节点主动向源站拉取接下来几个分片缓存到本地，用户不是只看当前分片，看完之后马上播下一个,预取可以避免每个分片都触发一次回源。
用动态扩缩容应对回看流量波动
回看的流量曲线比直播更不规则，直播开始前流量爬升，结束后断崖式下降，回看高峰可能出现在晚上8点到10点，也可能因为社交媒体上的一个讨论突然在凌晨2点爆发，静态地保持大集群很浪费,动态扩缩容必须做好。
指标选取很关键，CPU和内存使用率作为扩缩容依据有滞后性，更推荐用每秒请求数（QPS）和回源成功率作为主指标，当QPS超过集群承载阈值的70%，开始预热扩容；当回源成功率低于95%,立即扩容边缘节点。
扩缩容粒度要做到分片级别，每个分片服务集群独立扩容，不要整个服务一起扩，热门节目的分片集群可以扩到10个实例，冷门节目的集群保持2个实例就行，这需要把业务维度拆分到路由层,通过请求URL里的节目ID哈希到不同的集群。
直播转点播回看场景并发模型设计的常见问题
回看时用户拖动进度条，会不会拖垮服务器？
不会，但需要保护机制，播放器拖动会触发新的分片请求，后端要限制每个用户的分钟级最大请求次数，比如每30秒最多请求20个分片，超出后返回等待重试，另外建议开启快进快退的预览模式，用户拖动时只加载缩略图,松开后才拉流。
回看请求量大，但实际播放时长很短，如何优化资源？
大量用户可能只看了2秒就退出，这在回看场景很常见，可以在播放器初始化时只获取首个分片和元数据，不要预加载完整播放列表，用户真正播放超过5秒后，再请求后续分片，同时记录用户播放深度，低于10秒的会话不计入并发数,这样容量规划时能更准确。
是否所有回看内容都需要多码率和DRM？
不是，综合历史数据，超过60%的回看请求集中在最近48小时的内容，老节目的播放量非常低，按时间分层配置资源，新内容启用多码率和DRM加密，老内容只保留高清版不加密，能节省相当一部分成本,这里的关键是成本与并发能力的平衡。
回看场景的并发模型没有统一的标准答案，核心原则是把突发流量拆成可控的小块：热点分片靠CDN缓存，非热点分片靠合并回源，转码任务靠队列削峰，扩容操作靠指标提前触发，把这几层控制住，就能在不过度投入硬件的前提下,给用户顺滑的拖动回看体验。