DaraW

Code is Poetry

浅谈 B 站新 BV 号的设计

最近 B 站将 AV 号切换到了 BV 号,在知乎引起了较广泛的讨论,本来我只是吃瓜群众,但是在知乎上看到了一个说用 MD5 当地址的回答,我评论 MD5 不可行后,评论区有不少人质疑我,因此写了一个回答来解释为什么 MD5 不可行,以及我对 BV 号的看法。感觉这其实是一个很有意思的问题,所以将我的回答搬到了这里。

以下是我的回答原文:

反对 @V6.47 说的用 MD5 作为地址的回答,我理解 @V6.47 写这个回答多半出于调侃,但是评论区还真有不少人觉得这个方案是可行的。

问题的本质

回到这个问题本身,AV / BV 号本质是个 ID,即「如何设计 AV / BV 号」的本质是「如何设计视频 ID 生成器」,这个问题和「短 URL 系统是怎么设计的?」非常相似。

哈希为何不可行

哈希算法是摘要算法,无限的信息量(视频信息)转换为有限的信息量(定宽字符串),碰撞是必然会发生的。只要有碰撞的可能,那这个方案就是绝对不可行的。

有人补充说我检测一下是不是碰撞了,碰撞给它加 1 / 加 2 / 加3 … 行不行?理论是可行的,但是这样带来了一个成本,每次发号的时候还要去库里查一下这个号发过了没。如果数据量小还好,但 B 站在切 BV 号之前似乎 AV 号就已经发到了 9000W+,每次发号前加锁去 9000W+ 中搜一遍甚至更多遍,发完号再释放锁,这个 ID 发号器的性能绝对是不合格的。况且从存储与搜索的角度来说,一般的存储是基于 B Tree 或类似数据结构的,不能用哈希值作为索引键是基本常识,哈希的随机性会导致写入性能非常差,这也是为什么一般 ID 生成器生成出来的 ID 即使不是严格递增也是趋势递增的。

从安全的角度来讲,MD5 很多年前就已经是不安全的哈希算法了,用 SHA-1 也比 MD5 强,虽然 SHA-1 也已经不安全了,但好歹 SHA-1 目前公开的也只有 Google 在 17 年发布的碰撞案例,而 MD5 的碰撞成本几乎已经没有门槛了。

同样的道理,如果我们要做文件相同性校验,可能是防搬运,也可能是做网盘的秒传功能,用 MD5 在数据量不是大到极端的场景下是没问题的,但发现 MD5 相同时,是一定要再用一些手段去防止 MD5 冲突的:文件元信息比对、换一个哈希算法再算一下等等。

正确的做法

B 站的做法其实就是正确的,B 站这么多年才不到一亿个号,单机发号性能都足够用了,在连续递增的时候使用数据库自增 ID 或者自己实现一套自增 ID 就可以完美的满足需求。如果要求不连续,取消连续递增的逻辑即可,中间可以跳过一部分号不用,或者引入类似 Snowflake 的算法。

更多的可以参考短 URL 的那个问题,基本是相通的。

回到问题本身

单从技术角度,其实 B 站的说辞是站不住脚的:

容纳更多投稿
显然 AV 号作为数字,就算视频数量暴增,也是完全够用的,加一位就可以再获得当前容量的十倍。

保护稿件信息安全
大家的解读不外乎两个点:连续 ID 更容易被爬取,通过 ID 就可以看出来 B 站每天新增的视频数和总视频数。

目前新的 BV 转出来的 AV 已经不是连续的了,即 AV 号的生成已经换了新的方案,那么 BV 号的出现实则解决了不存在的问题

老的连续的 AV 号是继续保留的,且提供了 AV 到 BV 的转换,那想爬老的依然可以爬;
新的不再是连续的 AV 号生成方案也已经解决了这两个问题,完全没有搞出 BV 号的必要,只需要告诉大家新的 AV 号不再是连续的就 OK 了。

结论

由上可以推断,B 站对 BV 号的解释其实是站不住脚的,BV 号的出现,更多的可能是出于产品层面的考虑。

参考阅读

Proudly powered by Hexo and Theme by Hacker
© 2020 DaraW