【问题标题】:How does youtube calculate the unique 11 digit code for each video [closed]youtube如何计算每个视频的唯一11位代码[关闭]
【发布时间】:2013-12-27 05:12:29
【问题描述】:

Youtube 似乎对每个视频都有一个唯一的 11 位代码。该代码包括1-9,A-Z,a-z,以及一些符号,如+_*等。

他们将如何计算每个视频的唯一代码?我正在做一些事情,我想为每条记录分配一个唯一的代码,所以这个问题。

我的问题/疑虑是:

  1. 如果他们即时制作(提交视频时),那么他们必须检查为视频准备的代码是否已经存在?对于像他们这样的庞大数据集,这将是一项昂贵的操作。
  2. 他们是否会每晚或每月运行批处理作业之类的东西,以创建唯一代码并将它们存储在数据库中。然后在提交视频时,它只需要一个代码并将其标记为“已使用”
  3. 为数据库中的每条记录采用自动生成和自动递增的 ID 列,然后以某种方式将唯一的 ID 列转换为 11 位代码是否有意义?

我的目标是:

  • 为表中的记录创建唯一代码。
  • 用户可以与任何人共享带有该唯一代码的 URL。
  • 当有人通过唯一代码进来时。然后他们的“进来”与使用唯一代码共享 url 的原始用户联系在一起。

【问题讨论】:

  • 这些数字可能在内部是连续的,并以更简洁的表示形式表示,没有重叠的可能性。您描述的字符集正好有 64 个值,这意味着表示可能只是基数 64。
  • 这个问题似乎跑题了,因为它需要读心术。

标签: java algorithm youtube


【解决方案1】:

大致了解 GUID 和 UID。

大多数情况下,如果您使用的数据库将为您生成唯一 ID,然后该唯一 ID 可以编码为数字和字母以缩短生成的字符串。

http://en.wikipedia.org/wiki/Globally_unique_identifier

缩短字符串是关于你编码值的方式,它实际上并没有改变它。

例如,以 10 为底的数字 15 使用两位数,在十六进制中使用一位 (f) 在二进制中使用 4 (1111)。

以同样的方式,您可以使用 a-z、A-Z、0-9 并获得 base 62 以使用比使用 base 10 少得多的数字将数字编码为字符串。

这不是唯一的方法,但(特别是如果您已经有数据库行)它是最简单的。除非你真的想要,否则你甚至不需要填充到 11 - 但是在编码字符串的开头添加任意数量的 0 不会改变它的值。

Java 甚至提供了函数来为您执行此操作,尽管这些函数的最大基数是 36:

http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#toString%28int,%20int%29

【讨论】:

  • 缩短 GUID 不会破坏其独特性的目的吗?
  • 编辑添加更多解释。
  • 一个 11 位的 base64 字符串包含 66 位,或略低于 10^20 种可能性。可能足够好,但绝对不是防碰撞的。但是,如果它包含一个全局时间戳(置换?)它可能就足够了。
  • @JimGarrison 我怀疑他们是否担心会破坏 7,378,697,600,000,000,000 个视频。我认为即使是谷歌也无法为此争得足够多的驱动器
  • @Floegipoky 这不是一个顺序分配的数字...它是随机生成的(可能包含时间戳,也可能不包含),因此发生冲突的可能性非常小。
【解决方案2】:

对所有可能的 URL 使用散列函数,然后根据索引数据库对其进行检查的问题在于,它消除了同步的可能性。考虑上传视频所需的时间,根据他们的数据库检查它几乎不需要时间,这不是问题。当您考虑预先计算时会发生同样的问题:如果您想使用分布式计算机,则需要通过单点访问进行同步,我相信他们会这样做。我认为您的第三点可能最接近正确,然后出于某种原因将该 ID 以某种方式编码为更长的数字(我实际上不确定它与 int 值相比有什么优势;有人有充分的理由吗? )

【讨论】:

    【解决方案3】:

    这是一种有效地做到这一点并使其看起来随机的方法:-

    1. 制作一个 M 大小的哈希表,尽可能大。

    2. 使用哈希表查找随机生成前 M 个数字。

    3. 用尽时执行以下链接中建议的算法(抱歉重复使用类似问题的解决方案)。

    Generate unique phone numbers

    编辑:-我知道给定的解决方案是针对数字的,但您始终可以使用每个数字的简单映射将数字转换为符号。

    【讨论】:

      【解决方案4】:

      所有这些来回导致我对 youtube 的后端进行了更多研究。这是我想出的。

      This 让我相信他们正在使用 MySQL 来存储视频元数据。以下某些内容将取决于他们使用关系数据存储的假设。

      我认为11个字符的base64 id实际上是base64编码的64位值。 64^11 = (2^6)^11 = 2^66,这与 2^64 太接近了,不可能是巧合。

      我强烈怀疑此 id 的一部分来自存储视频元数据的分片的 id。假设他们将 24 位 (16,777,216) 用于分片 id。他们可能会使用整个范围,但他们没有 1600 万个分片。相反,他们可能会为每个分片分配这些分片 ID 的范围以简化重新分片。分配给给定视频的分片 id 可能是伪随机的。当分片开始填满时,他们将其拆分并更新范围。很简单。

      至少一部分剩余位可能是分片本地的自动递增值。

      如果在此之后还有任何位,它们可能被伪随机数、时间戳或类似的东西占据。它们也有可能包含其他特定于实现的数据,但如果它们不得不迁移,这可能会导致大问题,所以我怀疑它们会回避这个。

      【讨论】:

        猜你喜欢
        • 2018-01-27
        • 1970-01-01
        • 2016-03-05
        • 2019-05-05
        • 1970-01-01
        • 2020-10-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多