@hehezhang 不使用工具就是要机器 ssh 互通然后 scp 拷贝执行对应的脚本

@GreatTony 哎呦，这个可以，mua~

对比度的原因吧；想知道这种图片咋找

说了一堆，都不丢个地址让我们瞅瞅你的收藏😂

@Nillouise nosql 选型是啥

还有上报到存储，这中间应该一些架构流程支撑上报的并发量

数据存储方面，b 站给出的日活是 5000w，假设平均每个用户每日观看 60 个视频，那么数据量 60*30*3*0.5 = 2700 亿；

历史记录如果是传统数据库的话，这个数据量需要分库，用 user_id 和 timestamp 做一个联合索引应该就可以查到了；

不过历史记录存在修改的情况，同一个视频可能会被再看一遍，时间戳会修改；

服务解耦，异步处理都是；
防止瞬时峰值压垮服务；正常情况下处理能力是能够处理过来消息量的（你的服务至少要支撑起常态的访问量吧），但是一旦发生某些情况，比如什么活动啊，可能会有瞬发峰值产生，没有消息队列，可能会压垮某个服务；有了消息队列只是暂时消费服务没有处理完而已，不会被压垮；等消息量正常后，下游就可以处理完了；

@mooyo +1
@snowwalf 大佬，堆栈打点具体是怎么做的啊

@K4 没毛病，全加上，用不用再说_(:з」∠)_

那有没有必要全部加上 context 字段往下传递，作为后续预留使用？

@realbender 现在是没有使用到 context 的，有没有必要在逻辑函数里加上 context 参数往后传递，方便后续扩展使用