短链接系统设计思路

设计短链接系统

短链接转换是将任意一个长的 url 如 https://github.com/ChinaLym/Shoulder-Framework 转为一个固定长度的url，如 itlym.cn/sd5D1R，并可以通过访问短 url 来跳转到长url上。

场景举例

• 用户分享动态内容时有字数限制（微博、推特、朋友圈），如果分享一个长网址，很容易就超出限制，发布出去。短网址服务可以把一个长网址变成短网址，方便在社交网络上传播。
• 调用短信服务发送短信时，会有字数限制或因字数长短收取不同费用。

设计考虑点

如何设计一个可靠的短链接系统

短链接格式

由于url字符限制，推荐为大小写字母加数字，共62种字符。一般 6-7 位即可满足大多数场景。

真实链接与短链接映射关系

一对一还是一对多映射？

一般而言，采用 1对1 能够极大的减少存储空间，但是若采用 1-n 的关系，可以统计更多的信息，如短链接创建用户，创建时间、真实链接的访问是通过谁分享的等，短链接最有价值的地方其实就在于访问统计，因此采用一对多的方式是较好的。

短链接的生成方式

推荐使用全局唯一标识，不推荐将源链接进行摘要运算等方式，一是满足1对多映射关系，二是为了避免哈希冲突。

• 全局id生成器（可以考虑雪花算法）

存储设计

根据正常访问量计算，一般来说，传统的关系型数据库足够了，如果是短链接提供商，可能需要缓存

字段	含义
id	一般为短链接或其对应的 long
url	真实源连接
uid	生成这条记录的用户标识
password	短链接访问密码
visit_num	访问次数
status	状态：激活、过期、屏蔽等
tag	标签，用于分类
create_time	创建时间
update_time	更新时间（密码、状态）

重定向使用301还是302

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

提速

为了提高系统的性能，可以进行如下设计

• 根据短链接id还原一定的信息，如用户信息、url域名等
• 合理利用布隆过滤器等方案进行校验和过滤

预防攻击与回收

业务增长或遭到攻击会导致生成大量短链接，如何优化？

短链接系统必须要防范攻击！

• 限制IP/用户的单日请求总数，超过阈值加入黑名单且拒绝服务。
• 用Redis 存储源网址->短网址ID，仅存储一定时间以内的数据，用LRU机制进行淘汰。短时间内同一个长网址返回缓存短链接。
• 监控系统中存在的短链接数量和内容，回收长时间不被访问的链接，屏蔽投诉过多的链接。
• 检测垃圾内容，根据原地址中的关键字判断是否为垃圾信息。

特殊需求

设计中可以根据自身需要，合理决定是否要包含以下需求

增值服务

保留一下比较好的或极短的短链接，如 itlym.cn/66666，如 itlym.cn/yes，这类往往是APP跳转，某官网等固定不变的地址

允许用户自定义短链接

还需要考虑如下

• 是否带租期
• 长度要求
• 是否需要密码

跳转后浏览器上的地址栏仍显示短链接

在服务端渲染一个简单的网页，内嵌一个 iframe 用于打开目标网址

短信的链接直接跳转到APP

• 通过 Deep Links（iOS 则是Universal Links），可以实现点击短信链接直接唤起 App
• 如果系统因为各种原因不支持 Deep Links，备选方案是 intent filter，不过会出弹框让用户选择用哪个 App 打开链接
• 如果用户没有选择我们的 App 而是选择了浏览器打开，则通过 自定义 scheme 尝试唤起 App（忽略不支持 自定义 scheme 的浏览器）
  
  安卓链接跳APP

其他

快速实现

如果不是特殊需要，可以采用已有的解决方案

• 借助第三方
  • 百度短网址 http://dwz.cn/
  • 谷歌短网址服务 https://goo.gl/
• 私有部署
  • YOURLS
  • short_url

参考

https://www.zhihu.com/question/20103344