这是一个创建于 1880 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天在 b 站看视频，感觉不太爽，就准备在电脑上看，手机刚关，然后在 pc 端播放历史里面点开了；
突然想到，这个历史记录的实时性还可以啊，应该是实时上报到服务器的；历史记录加载速度也挺快的；然后又看了下，历史记录大概存了 3 个月，以 b 站这个用户量，数据量也不少了；
比较好奇这部分是怎么设计的，有没有大佬一起讨论下？
第 1 条附言 2020 年 12 月 1 日
在页面上看了下，上报是通过 heartbeat 接口进行上报的，在视频开始和暂时时都会触发心跳，视频播放中是每 15 秒进行一次心跳；
心跳包含：播放时长、视频 id （ bvid ）、时间戳和一些 id 等字段；
那么在视频开始时，历史记录已经上报了，用户在拉取的时候就可以拿到，最多上次观看时间点会有些偏差；
心跳包含：播放时长、视频 id （ bvid ）、时间戳和一些 id 等字段；
那么在视频开始时，历史记录已经上报了，用户在拉取的时候就可以拿到，最多上次观看时间点会有些偏差；
 | 1 cincout 2020 年 12 月 1 日 这个并不是实时的，至少手机上不是，app 端是关闭当前播放页面，才会记录到历史记录里面 |
 | 2 Anarchy 2020 年 12 月 1 日 via Android 就在退出页面，或熄屏的时候上报一次就够用了吧 |
 | 3 chloelam101 2020 年 12 月 1 日 OTT 来说，我是做电视的，基本上在播放器所有行为都要上报 timeline,因为多端，会做本地一份，上报一份。如果再次进入有校正 timeline 的，总体来说要保证多端同步。本地的话，如果是电视的话，多数做一个暂存器，先进后出那样子。 |
 | 4 shhch OP 数据存储方面，b 站给出的日活是 5000w，假设平均每个用户每日观看 60 个视频，那么数据量 60*30*3*0.5 = 2700 亿； 历史记录如果是传统数据库的话，这个数据量需要分库，用 user_id 和 timestamp 做一个联合索引应该就可以查到了； 不过历史记录存在修改的情况，同一个视频可能会被再看一遍，时间戳会修改； |
| 5 shhch OP 还有上报到存储，这中间应该一些架构流程支撑上报的并发量 |
 | 6 u2r1Hqo6HExmNsrt 2020 年 12 月 2 日 这东西用 nosql 搞根本不是问题吧，又不需要事务。nosql 可以线性扩展机器，用户量都不是什么问题。 |
| 7 shhch OP @Nillouise nosql 选型是啥 |
 | 8 eric96 2020 年 12 月 3 日 aws 的 dynamodb，支持 ttl，写入读取可扩展 |
Select Language