短连接系统

使用场景(Scenario)

微博和Twitter都有140字数的限制，如果分享一个长网址，很容易就超出限制，发布出去。短网址服务可以把一个长网址变成短网址，方便在社交网络上传播。

需求(Needs)

• 将长连接变成短连接
• 用户访问短连接，会跳转到正确的长连接上

 

短网址的长度

当前互联网上的网页总数大概是 45 亿，45亿 超过了 2^32 ，但远远小于64位整数的上限值，那么用一个64位整数足够了。微博的短网址服务用的是长度为 7 的字符串，这个字符串可以看做是 62 进制的数，那么最大能表示 62^7 个网址，远远大于 45 亿。所以长度为 7 就足够了。这个量级远远超过互联网上的 URL 总数了，绝对够用了。现代的 web 服务器（例如Apache, Nginx）大部分都区分 URL 里的大小写了，所以用大小写字母来区分不同的 URL 是没问题的。

[a-z,A-Z,0-9] 这62个字母或数字组成的7位的字符串。

一对多映射

一个长网址，对应一个短网址，还是可以对应多个短网址？

一般而言，一个长网址，在不同的地点，不同的用户等情况下，生成的短网址应该不一样。这样，在后端数据库中，可以更好的进行数据分析。如果一个长网址与一个短网址一一对应，那么在数据库中，仅有一行数据，无法区分不同的来源，就无法做数据分析。

以这个7位长度的短网址作为唯一ID，这个ID下可以挂各种信息，比如生成该网址的用户名，所在网站，HTTP头部的 User Agent等信息，收集了这些信息，才有可能在后面做大数据分析，挖掘数据的价值。短网址服务商的一大盈利来源就是这些数据。

如何计算短网址

现在我们设定了短网址是一个长度为7的字符串，如何计算得到这个短网址呢？

• 自增id

  • 无碰撞的方法，没新增一个短码，就在上次的短码id上加1，然后把这个10进制的数，转成一个62进制的字符串。
  • 可以利用数据库表中的自增id来完成，每次先查数据库表中自增id最大值max，然后max+1转成62进制数
  • 短码id是从一位长度递增的，长度不固定，可以指定id从某个数字开始，确保所有短码长度一致。同事短码是有序的，可能有安全问题，所以将生成的短码id结合长网址等其他关键字，进行MD5运算生成最后的短码。

• 普通随机数

  • 利用Math.round()生成随机数，如果库中存在这个id就重复生成随机数。
  • 这种情况下，发生碰撞的可能性不小，可能要多次循环才可以生成一个不冲突的短码。

• 摘要算法（哈希算法）

  • 输入任意长度的数据，输出固定长度的数据，相同的输入对应相同的输出，不同的输入尽量拿到不同的输出。
  • （1）将长网址md5生成32位签名串,分为4段, 每段8个字节；
  • （2）对这四段循环处理, 取8个字节, 将他看成16进制串与0x3fffffff(30位1)与操作, 即超过30位的忽略处理；
  • （3）这30位分成6段, 每5位的数字作为字母表的索引取得特定字符, 依次进行获得6位字符串；
  • （4）总的md5串可以获得4个6位串；取里面的任意一个就可作为这个长url的短url地址；
  • 也会发生碰撞，但是碰撞几率小，一单发生碰撞的话解决冲突比较麻烦。

• 利用Redis号段模式

  • 将 62^7的 ID 进行分段，比如分为 N 段，前 K 位一致。那么剩下的位就可以通过 Redis 来进行生成，防止重复。
  • 假设要获取一个号段，比如（1,1000]的，只需要在本地利用redis自增一个id就可以，

如何存储

• 数据库存储

  • 域名，链接除域名外的后缀，完成链接，生成的短连接，短链接失效时间，当前链接总的点击次数。
  • 因为短链接需求可能是相关活动或者热点数据，所以过滤一定时间热潮会持续衰退，没必要永久保存增加每次查询的负担。

• 数据库分表

  • 如果一条数据是10b的话，总容量是45亿×10b，单表肯定无法支撑，所以要分表。
  • 假设分成100张表的话，每张表名通过数字区分。可以通过短链接做encoding编码生成数字类型，然后做路由找到表。

• 缓存存储

  • 查询需求：如果是几百G的数据量放缓存是不合适的，可以将近3个月的查询或者新增URL放入缓存，使用LRU算法进行热点更新。这样，最近使用的命中缓存概率会高，查不到在查库更新缓存。
  • 新增需求：新增的就先查缓存是否存在，缓存没有再查库，库的话可以分表，查询率不会很低。
  • 缓存设计：用户用短链接查真是地址，缓存key是短链接，使用KV存就可以。

如何跳转

当我们在浏览器里输入 http://bit.ly/a3300 时

1. DNS首先解析获得 http://bit.ly的 IP 地址
2. 当 DNS 获得 IP 地址以后（比如：12.34.5.32），会向这个地址发送 HTTP GET 请求，查询短码 a3300
3. [http://bit.ly 服务器会通过短码 a3300 获取对应的长 URL
4. 请求通过 HTTP 301 转到对应的长 URL http://www.theaustralian.news.com.au/story/0,25197,26089617-5013871,00.html。

301是永久重定向，302是临时重定向。短地址一经生成就不会变化，所以用301是符合http语义的。但是如果用了301， Google，百度等搜索引擎，搜索的时候会直接展示真实地址，那我们就无法统计到短地址被点击的次数了，也无法收集用户的Cookie, User Agent 等信息，这些信息可以用来做很多有意思的大数据分析，也是短网址服务商的主要盈利来源。

所以，正确答案是302重定向。

可以抓包看看mrw.so的短网址是怎么做的，使用 Chrome 浏览器，访问这个URL http://mrw.so/4UD39p，是我事先发微博自动生成的短网址。来抓包看看返回的结果是啥，可见新浪微博用的就是302临时重定向。

参考：https://www.cnblogs.com/rickiyang/p/12178644.html