微小的URL系统设计

如何解决微小的URL系统设计

我阅读并观看了许多 YouTube 视频和链接，它们都提供了相同的解决方案：

使用像zookeeper这样的分布式计数器
柜台最大限额可以是 3.5 万亿
将计数器值转换为 Base62

当计数器值很小时，这一切都很好。例如生成的计数器值：120001 => base62 值 FMJQmhBR

但是当计数器提供像低于 base62 值的大计数器值时，长度也会增加。生成的计数器值：120003658=> base62 值 HRGZF8RiHC6y

那么这怎么能成为长度为 8 的精确小 url 的解决方案。

https://www.linqz.io/2018/10/how-to-build-a-tiny-url-service-that-scales-to-billions.html https://www.youtube.com/watch?v=eCLqmPBIEYs https://www.youtube.com/watch?v=JQDHz72OA3c&t=1862s

解决方法

首先：绝对有一个压缩限制。如果您选择的表示具有最大长度，则会对您的密钥空间施加硬限制。

让我们把它拆开一点。假设您有 80 位客人参加聚会，并且您想给每位客人一个独特的标签（用于他们的饮料杯或其他东西）。如果您决定每个标签都是英文字母表中的一个字母，那么您只有足够的唯一标签供 26 位客人使用。

第二：FMJQmhBR 不是表示数字 120001 的最有效方式。它需要 17 位二进制：11101010011000001（不确定是哪个 endianness）。 16 位只是两个 ASCII 字符，三个 ASCII 字符可以容纳近 1700 万个唯一值。而且没有任何特殊的、类似 ZIP 的压缩。

我认为大多数 URL 缩短器的工作本质上是通过为某人缩短的每个 URL 分配一个计数数字来工作的。因此，提交的第一个 URL 将被赋予 ID=1：他们将整个 URL 保存在数据库中并将其与该编号相关联。第二个 URL 获取 ID=2，依此类推

不过，这很粗糙。由于各种原因，他们不想按顺序分发这些 ID。但是如果他们知道他们想要标识符的长度，那么按随机顺序分发这些 ID 并不难：

当有人提交网址时，系统会选择一个介于 0 和可能的最高 ID 之间的随机数。如果 URL 标识符都应该是 8 个 ASCII 字符，这意味着它们会在 0 到 2^(8*8) = 1.844674407e19 之间选择一个随机数。
然后他们检查他们的数据库，看看他们是否已经分发了那个 ID。如果有，他们会选择一个不同的随机数。他们重复此操作，直到他们选择了尚未分发的 ID。（我认为对此有更有效的算法，但效果是一样的，而且这个最容易理解。）