«

»

Mar 24 2020

如何看待如何看待哔哩哔哩将稿件的「AV 号」变更为「BV 号」以及如何看待哔哩哔哩将稿件的「AV 号」变更为「BV 号」

我真心没打算写这篇文章!

但如果非要让我简单来讲:两伙智障势利对线

1. 非技术上的

先说非技术层面上的

你们这些在各个社交平台的讨论都:

关我屁事!

2. 技术上的(猜测)

再说技术层面上的个人猜测。

首先这种 BV1d7411F7Z8 写法让我想到的这就是 BaseXX 写法,可以直接反转成一个纯数字字符串,这种字符串让我联想到了之前看到过的一些资料。

Sharding & IDs at Instagram

如果你不想读或者读不懂的话,我可以简单解释一下:这是一种对数据库友好的写法。

首先数据库需要为每一条数据(以B站为例的话就是每个投稿了)记录一个 ID 号,这个 ID 号至少包含这几个特征:

  • 自增
  • 唯一
  • 索引

使用连续自增索引是最简单的办法,av90777006 下一个就是 av90777007 。

问题是这种办法一旦上了分布式数据库就会很棘手,为了协商半天到底哪个是先提交的哪个是后提交的,可能会很恶心。(注:这是一道经典且恶心的面试题,如果你去网上搜索答案的话会发现很多公司的解决办法更恶心。)
(所以 mongodb 比较火,你经常会发现很多公司的后端业务上莫名其妙会有一个 mongodb 但是并不做什么很高大上的事情)

但如果搞清一个前提:自增索引 特性并不需要基于 连续,那么其实 你第一条 ID 是 1,第二条 ID 是 10000,是不会影响查询效率的,只要保证第三条比 10000 大就可以了。

Twitter 和 Instagram 都用过这个特性而实现自己的算法,用一个长数字字符串,前半部分用时间戳,后半部分用工作机器ID,来生成这种 ID 。只不过 Twitter 是用的纯数字,Instagram 则是用的 BaseXX 转换。

而且鉴于 B 站并不是简单的帖式服务,所以其实还可以在这种复杂 ID 场景下做更多的文章,可以绑定更多关联 ID 以减少查询次数。

数据库优化

到这里其实这个话题就该结束,上面这句就是如何看待如何看待哔哩哔哩将稿件的「AV号」变更为「BV 号」的结论。

3. 实际上的

现在 Web 前端其实是去拿 BV 号到后端请求回 AV 号的。

snap_at_597

鉴于这是一种对产品功能的大改,我觉得对于产品的迭代,这种妥协是可以接受的。

然而

实际上知乎上已经有人反推出来了 BV 转 AV 的算法,甚至还有 离线的 Web 实现

结论是:

  • 「AV 号」和「BV 号」是对应关系,后端仍然以「AV 号」为自增基准。
  • 「BV」号只是 「AV号 」加了堆固定参数后,私有字典的 Base58 。

知道了真相之后:

数据库优化个球球

4.参考资料

(留评论请注意文章的时效性)

3 comments

  1. 萃香西瓜

    一般分布式数据库下唯一id都是用分片来做的,每台机器先预先申请一个号段(而不是普通的只拿一个id),只要每台机器的号段之间相互不重复就可以了

    这次BV号我猜测最主要目的是为了防止视频id可以被简单枚举,从而被各种营销站点把视频按区间爬虫下来。至于为什么原理还能看到bv转av,可能是过渡方案,毕竟这么大改动还是要留后路的,万一bv方案有各种问题还能降级,同时各个上下游系统改动量最小

    1. 石樱灯笼

      所以说我真心没打算写这篇文章

  2. 陈大猫

    改了个URL的表现形式而已,没想到这么多人关注和讨论的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据