这是一个创建于 1480 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天在 b 站看视频，感觉不太爽，就准备在电脑上看，手机刚关，然后在 pc 端播放历史里面点开了；
突然想到，这个历史记录的实时性还可以啊，应该是实时上报到服务器的；历史记录加载速度也挺快的；然后又看了下，历史记录大概存了 3 个月，以 b 站这个用户量，数据量也不少了；
比较好奇这部分是怎么设计的，有没有大佬一起讨论下？
第 1 条附言 · 2020-12-01 19:25:59 +08:00
在页面上看了下，上报是通过 heartbeat 接口进行上报的，在视频开始和暂时时都会触发心跳，视频播放中是每 15 秒进行一次心跳；
心跳包含：播放时长、视频 id （ bvid ）、时间戳和一些 id 等字段；
那么在视频开始时，历史记录已经上报了，用户在拉取的时候就可以拿到，最多上次观看时间点会有些偏差；
心跳包含：播放时长、视频 id （ bvid ）、时间戳和一些 id 等字段；
那么在视频开始时，历史记录已经上报了，用户在拉取的时候就可以拿到，最多上次观看时间点会有些偏差；
 |
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，写入读取可扩展
|
Select Language