高并发场景下如何设计播放器上报播放进度？

[RunningRabbit]

视频播放进度如何合理设置上报事件？保证最新的播放进度记录，目前是每 30 秒上报一次，离开时上报一次，高并发情况下，接口处理不过来，前端从播放器返回或者直接杀死 app 保证会上报吗？

[RunningRabbit]

@janus77 我的问题描述有点跑偏了，想确认前端的上报时机是不是存在可优化的空间

[richard1122]

“每 30 秒上报一次” 是分布开的吧？
而不是写了在固定的每分钟的 0 秒和 30 秒上传吧。。

[neptuno]

@RunningRabbit #8 把用户均分一下，虽然是 30 秒一次，例如 uid 结尾是 1 的就是每分钟第 1 秒和 31 上传，每秒没多少请求的

[RunningRabbit]

@swulling
@blankmiss
@FrankAdler 这种方案可以解决问题

[yuanchao]

放队列里跑就行了，后端接口收到请求后直接塞队列，数据量较大就加消费者就行，我司就是这么干的，支撑了一百多万学生在线上课

[yuanchao]

并且我们是 3s 上报一次，当用户产生行为时也会上报（拖动进度，关闭浏览器）

[yufeng0681]

这个视频播放进度的特性不那么重要，不能影响主要业务的接口性能
1 、建议走其他域名（比如统计行为类的）的服务器进行上报
2 、redis 定时清掉不再播放的视频进度条数据（存到数据库里去，下次用户上来的详细接口里返回进度条数值）

[shellwen]

这个一定要上 Redis 之类的，直接写 MySQL 肯定慢

[night98]

10 万用户咋可能顶不住，除非你接口直接写数据库，不然随便上个 mq 或者本地队列都不会有问题

[realpg]

服务端用 golang 写，后面 redis ，猴子都能写出单机 4C4G 跑 12 万 QPS ，挂个负载均衡猴子都能写出省资源的百万并发

现在我的项目，15 万同时在线播放视频用户，视频长度 1 小时每个（教育类），1 秒上报都扛得住

[realpg]

没写完就发出去了
现在 4C4G*2 跑 25 万用户（单机 4C4G 也没问题，只是为了热更新方便两台前面 SLB ），同时播放一般是 15 万用户左右（课程有时限，一节 40-70 分钟，但是总共开播的窗口就很短的，所以这些用户都得短时间集中看完并发很大）。

现在的上报机制是默认 1s 上报位置，服务器端每 10 秒钟会后台 routine 计算一下当前负载，如果负载过大的话，就会下发客户端上报时间变为 2s ，如果下 10 秒仍然负载过大，就变为 3s 以此类推，最大间隔 30 秒。而降低的机制是，如果接下来两个 10 秒负载降低到门槛，就会减少 1 秒，最少 1 秒

实际监控上看，服务器从来没高负载过，累计间隔变为 2s 以上的时候加起来一天不超过 5 分钟，而且更多的时候不是由于自身负载过大，而是进行热更新啊之类的，这时候 cpu 资源被其他进程占用堆起来的

[cassyfar]

关键是要用一个消息队列，然后负载均衡到后台一堆实例上写进数据库。这也是大并发分布式系统设计基操。

[RunningRabbit]

@yuanchao
@yufeng0681
@shellwen
@night98
@realpg
@cassyfar 大佬建议已收到，开搞

[hopingtop]

瓶颈 Mysql 写入，核心解决思路，控制 Mysql 写入更新量。

如果可以容忍最新进度的丢失的容忍性，和粒度放大问题。最低成本的解决方案：
本地记录最新的时间。拉长上报 最新进度上报时间间隔比如 3 分钟？ TPS 约 600 了。
退出立即记录退出时间。
客户：异常退出再进来利用本地记录恢复。本地没有取远端最新，导致进度可能不准，但是异常退出量少
正常退出再进来，利用远端退出时间记录。准确进度

1.这样改动最少 2 不引入其他额外组件，最低成本
缺点：统计的粒度不够细。

[work220602]

这不是 10qps 用户该考虑的问题

[uyoungco]

Redis 可以完美解决啊