今天在 b 站看视频,感觉不太爽,就准备在电脑上看,手机刚关,然后在 pc 端播放历史里面点开了;
突然想到,这个历史记录的实时性还可以啊,应该是实时上报到服务器的;历史记录加载速度也挺快的;然后又看了下,历史记录大概存了 3 个月,以 b 站这个用户量,数据量也不少了;
比较好奇这部分是怎么设计的,有没有大佬一起讨论下?
1
cincout 2020-12-01 18:31:30 +08:00
这个并不是实时的,至少手机上不是,app 端是关闭当前播放页面,才会记录到历史记录里面
|
2
Anarchy 2020-12-01 18:43:13 +08:00 via Android
就在退出页面,或熄屏的时候上报一次就够用了吧
|
3
chloelam101 2020-12-01 19:44:14 +08:00
OTT 来说,我是做电视的,基本上在播放器所有行为都要上报 timeline,因为多端,会做本地一份,上报一份。如果再次进入有校正 timeline 的,总体来说要保证多端同步。本地的话,如果是电视的话,多数做一个暂存器,先进后出那样子。
|
4
shhch OP 数据存储方面,b 站给出的日活是 5000w,假设平均每个用户每日观看 60 个视频,那么数据量 60*30*3*0.5 = 2700 亿;
历史记录如果是传统数据库的话,这个数据量需要分库,用 user_id 和 timestamp 做一个联合索引应该就可以查到了; 不过历史记录存在修改的情况,同一个视频可能会被再看一遍,时间戳会修改; |
5
shhch OP 还有上报到存储,这中间应该一些架构流程支撑上报的并发量
|
6
Nillouise 2020-12-02 08:44:24 +08:00
这东西用 nosql 搞根本不是问题吧,又不需要事务。nosql 可以线性扩展机器,用户量都不是什么问题。
|
8
eric96 2020-12-03 14:30:28 +08:00
aws 的 dynamodb,支持 ttl,写入读取可扩展
|