数据结构与算法简记--实现一个短网址系统

Posted 2021-03-14 杨海星

实现一个短网址系统

---

短网址服务

• 把一个长的网址转化成一个短的网址，访问这个短网址，就相当于访问原始的网址

• 原始网址：https://github.com/wangzheng0822/ratelimiter4j
  短网址：http://t.cn/EtR9QEG

• 上面第二个网址是通过新浪提供的短网址服务生成的

• 核心功能：
  • 把原始的长网址转化成短网址
  • 当用户点击短网址的时候，短网址服务会将浏览器重定向为原始网址
  • 

如何通过哈希算法生成短网址？

• 使用比较著名并且应用广泛的一个哈希算法：MurmurHash 算法
• 提供了两种长度的哈希值，一种是 32bits，一种是 128bits。为了尽可能短，可以选择 32bits 的哈希值
• 对于开头那个 GitHub 网址，经过 MurmurHash 计算后，得到的哈希值就是 181338494。
• 再拼上短网址服务的域名，就变成了最终的短网址 http://t.cn/181338494（其中，http://t.cn 是短网址服务的域名）。

 

• 如何让短网址更短？
  • 将 10 进制的哈希值，转化成更高进制的哈希值，这样哈希值就变短了
  • 在网址 URL 中，常用的合法字符有 0～9、a～z、A～Z 这样 62 个字符。
  • 为了让哈希值表示起来尽可能短，将 10 进制的哈希值转化成 62 进制。具体的计算过程如下图。最终用 62 进制表示的短网址就是http://t.cn/cgSqq。
  • 

• 如何解决哈希冲突问题？

  • 给原始网址拼接一串特殊字符，比如“[DUPLICATED]”，然后跟再重新计算哈希值，两次哈希计算都冲突的概率，显然是非常低的。
  • 假设出现非常极端的情况，又发生冲突了，再换一个拼接字符串，比如“[OHMYGOD]”，再计算哈希值。
  • 然后把计算得到的哈希值，跟原始网址拼接了特殊字符串之后的文本，一并存储
  • 当用户访问短网址的时候，短网址服务先通过短网址，在数据库中查找到对应的原始网址。
  • 如果原始网址有拼接特殊字符（这个很容易通过字符串匹配算法找到），先将特殊字符去掉，然后再将不包含特殊字符的原始网址返回给浏览器。
• 如何优化哈希算法生成短网址的性能？
  • 首先可以给短网址字段添加 B+ 树索引
  • 其次减少sql语句执行次数来减少通讯次数：
    • 给数据库中的短网址字段，添加一个唯一索引（不止是索引，还要求表中不能有重复的数据）
    • 当有新的原始网址需要生成短网址的时候，并不会先拿生成的短网址，在数据库中查找判重，而是直接将生成的短网址与对应的原始网址，尝试存储到数据库中。
    • 如果数据库能够将数据正常写入，那说明并没有违反唯一索引，也就是说，这个新生成的短网址并没有冲突。
    • 在大部分情况下，我们把新生成的短网址和对应的原始网址，插入到数据库的时候，并不会出现冲突
    • 通过布隆过滤器减少SQL语句执行次数：
      • 把已经生成的短网址，构建成布隆过滤器。
      • 布隆过滤器是比较节省内存的一种存储结构，长度是 10 亿的布隆过滤器，也只需要 125MB 左右的内存空间。
      • 当有新的短网址生成的时候，先拿这个新生成的短网址，在布隆过滤器中查找。
      • 如果查找的结果是不存在，那就说明这个新生成的短网址并没有冲突。此时，只需要再执行写入短网址和对应原始网页的 SQL 语句就可以了。
      • 通过先查询布隆过滤器，总的 SQL 语句的执行次数减少了。

如何通过 ID 生成器生成短网址？

• 维护一个 ID 自增生成器。它可以生成 1、2、3…这样自增的整数 ID。
• 当短网址服务接收到一个原始网址转化成短网址的请求之后，它先从 ID 生成器中取一个号码，然后将其转化成 62 进制表示法，拼接到短网址服务的域名（比如http://t.cn/）后面，就形成了最终的短网址。
• 最后，把生成的短网址和对应的原始网址存储到数据库中。
• 几个细节问题：
  • 相同的原始网址可能会对应不同的短网址
    • 不处理：用户只关心短网址能否正确地跳转到原始网址，不关心短网址长什么样子。
    • 借助哈希算法生成短网址的处理思想：当要给一个原始网址生成短网址的时候，先拿原始网址在数据库中查找，如果数据库中存在，就取出对应的短网址，直接返回给用户
  • 如何实现高性能的 ID 生成器？
    • 给 ID 生成器装多个前置发号器
    • 

       

       

    • 多个ID生成器
    •