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

[RunningRabbit]

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

[joesonw]

进度放本地呗，被杀掉的话，下次启动上传。

[tramm]

处理不过来? 不可能吧, 又没啥业务逻辑啊...

[yazinnnn]

多高的并发?

[aplusfran123]

是并发高到缓存 buffer 啥的都不够用？不太理解

[documentzhangx66]

处理不过来，应该先找瓶颈。

当然，省级系统，1C1G1M 的云主机，那肯定处理不过来。

[RunningRabbit]

@joesonw 放本地更换设备这些记录是不是没看不到了？

[yidinghe]

处理不过来的具体 QPS 是多少，如果服务端只是简单的将进度缓存起来，没有业务逻辑的话，不存在处理不过来的。

[RunningRabbit]

@tramm
@yazinnnn
@aplusfran123
@documentzhangx66 用户量比较大，10 万用户，每 30 秒上报一次，请求量确实挺大的。后端接口后面也做下优化

[RunningRabbit]

@yidinghe 是的，后端需有优化下存储这块，同时也想着优化下前端的上报逻辑

[yazinnnn]

@wangxl999999
10 万用户分钟两次请求也不过 20 万请求, 平均下来 qps 也就不到 4000 啊...
存到什么地方呢?

[joesonw]

@wangxl999999 你每 30 秒上传以外的数据临时放本地。

10 万用户是同时在线吗？不是每时每刻满负载的话，队列存一下，慢慢入库呗。

[documentzhangx66]

@wangxl999999

你这请求量：

1.建议用云 Redis 。

2.用之前，先问问产品经理，大概的性能。

3.问下产品经理能否开一台测试的，或者开一台按量计费的，压测一下性能，因为是按量计费，前期脚本准备齐全的情况下，系统部署 + 测试大概半小时能搞定，花不了几块钱。用完后记得把实例删掉，防止继续扣钱。

4.单台扛不住，用负载均衡。别用云主机做负载均衡，直接问产品经理买云负载均衡。

5.给你个数据，某省级视频播放系统，每天高峰期大概 5-8w 在线用户，10s 保存一次播放进度，云负载均衡 + 3 台 Redis 平均 CPU 负载 80% 左右。

[RunningRabbit]

@yazinnnn 存 mysql 数据库了,分表处理

[RunningRabbit]

@wangxl999999 好的，后面使用 redis 负载均衡优化下这块问题

[FrankAdler]

就这点 qps 和数据量 随便一个 mq 都打发了

[swulling]

看评论是直接落库了。

可以写到 redis 里或者写到 mq 里异步消费。

以你这个量级写到 redis 里最简单

[blankmiss]

确实 这种情况得选择 redis 或者 rabbitmq

[yazinnnn]

提供一个从程序上优化的思路, 播放进度只有最新的数据有意义, 把你的进度放到数据流里, 给数据流一个时间窗口, 比如 10 分钟, 10 分钟内每个(uid,vid)最新的进度才去落库

[paopjian]

视频不是切片了吗,应该是获取切片的时候或者长时间暂停的时候发送进度信息吧,而且可以全扔给 mq,反正不是重要信息

[janus77]

你这个属于后台的问题吧，发到安卓节点有啥用。。。