技术干货 | 高性能短链设计与实现
导读： 在短信和微博里面，我们常常看到类似这样的链接：https://t.cn/xxxx。为什么这里面的 url 都是短的呢？有什么好处呢？怎么做到的呢？接下来给大家简单介绍下设计这套系统所涉及的一些思路，希望对大家能有一些帮助。
文｜朱陈杰
网易云商服务端开发工程师
什么是 URL 短链
URL 短链就是把原来较长的网址，转换成比较短的网址。以下面这条短信为例：
上图中，https://dx.10086.cn/looGDg就是一条短链。用户点击蓝色的链接，就可以在浏览器中看到它对应的原网址：
http://wap.zj.10086.cn/case/mould/produce/9b032ecfcb9b42f6a8fc411d160d91e320200722001_750.html?chid_code=9c6d64&WT.mc_id=20210205zthgcsdx
为何要使用短链？来看看短链能带来哪些好处：
内容平台上（如微博、Twitter、小红书等），往往发文有长度限制，短链带来的好处不言而喻：网址短、美观、便于发布、传播，能写更多正文；
短信，如果超过字数限制，就会被拆成多条发送，如果短信量大也可以省下不少钱；
二维码，本质上也是一串 URL，长链的话二维码密集难识别，而短链则不会存在这种问题；
安全性，不想过于直观的暴露原始网址；
统一经过平台重定向，能对数据进行运营分析。
短链跳转的原理
我们还是以上面的短链为例，原理如图：
流程可分为三步
第一步：浏览器发起请求，请求地址：https://dx.10086.cn/looGDg
第二步：短链服务器收到请求后，通过短链接地址找到原始长链接。返回 http 状态码是301或302，同时也通过 location 响应头告知客户端：你要访问的其实是下面这个长网址：http://wap.zj.10086.cn/case/mould/produce/9b032ecfcb9b42f6a8fc411d160d91e320200722001_750.html?chid_code=9c6d64&WT.mc_id=20210205zthgcsdx
第三步：客户端收到短链服务器的应答后，再跳转至长网址：http://wap.zj.10086.cn/case/mould/produce/9b032ecfcb9b42f6a8fc411d160d91e320200722001_750.html?chid_code=9c6d64&WT.mc_id=20210205zthgcsdx
实际浏览器中的网络请求如下图：
这里简单回顾一下 http 状态码301和302的区别：
301代表永久重定向，也就是说第一次请求拿到长链接后，下次浏览器再去请求短链的话，不会向短网址服务器请求了，而是直接从浏览器的缓存里拿，在 server 层面就无法获取到短网址的点击数了，如果这个链接刚好是某个活动需要统计点击率，那结果只可能是0或1了，所以一般不采用301。
302代表临时重定向，也就是说每次去请求短链都会去请求短网址服务器，便于 server 统计点击数。虽然用302会给 server 增加一点压力，但是更符合业务需要，所以推荐使用302。
短链场景需求分析
短链服务需求分析：
功能性需求：
原始 URL 转短链
访问短链跳转到原始 URL
短 URL 访问过期
短 URL 非法失效
自定义短链接
短链的批处理
访问统计
支持 B 端多租户
非功能性需求：
高可用：支持分布式服务下的高可用。
高性能：无论是生成短链，还是访问短链，服务都要支持高并发、低延时。
安全性：短链不可被预测，避免接口被轮询导致数据泄露等风险。
系统容量预估
读写估算、存储估算、带宽估算、内存估算、缓存估算、总体估算：
存储预估：
假设，系统接入的某个业务一天生成100万短链接。那么一年下来预估为：100万*30 *12 = 3.6亿。
假设短链需要保存五年，且类似体量业务接入10个。存储五年的量预估为：3.6* 5 * 10=180亿数据量。
假设一条核心数据（长 URL、短 URL、创建时间和过期时间等信息）大小为0.5kb。那么存储180亿短链所需：180 * 0.5KB = 18T。
读写预估：
假设这一百万数据需要在一小时内发完，那么我们单机能承受负载可以这么来估算：
每秒写请求：
1000000 / 1 hour* 60 min * 60 sec = 278（Req/S)
每秒读请求（读多写少，我们按照读写100 : 1 来考虑）：
278 * 100 = 27800 （Req/S）
缓存预估：
缓存这部分计算可以参照读写请求的预估值，考虑业务的集中访问时间进行衡量。另外，如上文所提的场景，读远高于写的请求可以考虑加内存缓存，命中率会非常的高，这样对读性能又是一个显著提升。
短链长度预估：6位，可使用短链568亿
详细设计
短链生成算法
设计短链生成算法，本质就是找到f(x)，寻找“长”、“短”之间的映射关系，这就是短链算法的根本。
方案1：Hash 算法
首先，最容易想到的就是 MD5、SHA 等算法。
输入的长 URL 经过 MD5 算法的处理，会输出一串长度为 128 bit 的字符串。128 bit 的 MD5 通过 Base62的规则编码（A-Za-z0-9），会生成22位的字符串。显然22位还是太长了。那么如何拿到6位短链呢？
首先想到截取，假设按照转换出来截取它的前六位或者后六位，两个完全不一样的长链转换出来的字符它的前6位或者后6位一样的概率还是很高的。就会导致上面的“关系”错乱，两个长链对应了一个短链上。
另外有同学会说，在发现冲突的时候加随机或者加时间戳，或者加 IP 等等。方案改进可以降低冲突概率，但是还是会存在。如果冲突一直在，就要重复执行这段逻辑。
可以看出 MD5 这种方式不是很优雅，而且在效率上也不高。
方案2：自增序列算法
区别于 Hash 算法，全局自增 ID 方案的好处是不需要关心原始长链接。天然支持一对一这种映射关系。不会存在之前 Hash 方案中一对多这种问题。
所以初步的想法通过一个 ID 自增生成器，可以通过数据库 ID 自增、zookeeper 计数或者 redis 的 incby 或者自己实现一个自增计数器都行。程序收到请求后去拿一个 ID，然后将这个 ID 通过 Base62 转换成短链，然后插入这个映射关系。
但是方案2会存在以下几个问题：
问题1：每次来一个请求，比如说长链是一样的。那势必也会生成一个 ID。那如果有人刷接口或者重复提交，那很快 ID 资源将会耗尽。
问题2：如果是自增的 ID，规律性太强，很容易被人预测，导致信息泄露。
如何解决这些问题呢？
问题1：可以通过对长链加唯一索引解决，但是会加大存储空间，另一面因字段内容过多会导致数据库 page 记录减少，当发生插入或者删除等操作很容易产生分页，影响性能。所以可以考虑用布隆过滤器（Bloom Filter），当长链不存在时程序才给分配。
问题2：相对容易一点，可以增加一些随机性，在规则上做一些操作。比如加上数据中心，机器 IP 等，而不是简单的加一加二。
所以综上考虑使用 Snowflake + Bloom Filter 来解决核心算法问题。篇幅有限，如果不清楚细节的可以自行深入了解下。
架构设计
整体架构如图。自上而下，首先网络层，在 Nginx 做读写域名分离，考虑到响应、安全等问题，创建、访问统计、详情等请求走内网域名，访问短链跳转走公网域名。
整个短链中心结构大体分为三层：系统安全、应用安全及业务处理。首先请求进入限流中心，规则基于服务流控、业务线流控及租户维度流控，当系统发生异常时我们可动态调节系统流控，保证整体系统的稳定，提供能力。当某个业务线或者某个租户出现异常流量或者被刷等情况之后，我们可以考虑对某个租户限制访问，限制该租户的请求，避免连锁反应，导致系统崩盘。安全中心将对进入的短链进行一些规则校验，比如长度、字符内容等，如一些非法恶意的请求直接做拦截处理。
如果该请求是创建等接口，将会对传入的 Appkey 和 AppSecret 进行鉴权校验，如果校验通过，基于短链生成算法，生成短链接，存储到数据库，完成数据主从集群备份，同时异步更新到 Redis 缓存集群并且加载到内存缓存，同时更新到过滤中心服务。如果该请求是访问查询请求，程序将先判断该短链是否在布隆过滤器内。若存在，则先走内存缓存然后 Redis 最终到 DB，中间存在则立即返回；若不存在，则直接认定为非法短链。所以过滤中心非常重要，是维稳下层中间件安全的核心能力，防止异常流量对缓存或者数据库造成压力，进而引起雪崩。
数据库表结构设计
短链表设计核心字段如下：
保障系统稳定性
作为一个基础组件，必须要保证高并发的同时，还要考虑服务的稳定性及高可用。
首先是安全：
在服务上线之初，需要考虑几点。接口分类上大体分成两类，第一类是用户可以访问的短链接，另一类是用户无需感知且不能被感知的比如创建、查看详情、访问统计等等。首先要做的就是做好网络隔离，将用户可以访问的提供公网访问，不可访问的将网络限制机房或者办公网访问等。其次，接入的业务方需要分配指定的 Appkey 和 AppSercert ，核心接口调用进行必要的签名校验，防止一些恶意攻击流量对系统造成影响。
其次是限流：
为了让系统更加的健壮，这个时候就要考虑一些限流策略。可以针对整个服务或者接口做一些限流策略，可以基于 Guava 的 RateLimiter 或者在网关层做一些限制。防止业务流量飙升的时候，保证服务是稳定可用的。
最后就是防刷：
首先过滤掉一批非法请求，将传入的短链进行正则检验，不满足直接过滤。满足校验规则，通过布隆过滤器，如果外部请求某个短链不存在系统中，那直接过滤掉，避免一些恶意的请求进入到系统造成影响。短链需要考虑接入一些安全服务，对长链内容进行一些检测，防止涉黄涉暴等内容发生，封禁之后影响整个域名的可用性。所以需要在设计之初，考虑快速拉黑失效短链的能力。
总结
本文详细介绍了短链的设计方案，阐述了短链设计原理、容量评估、具体设计方案及稳定性等方面的内容。我们基于业务场景需求分析，针对如何设计一款基础好用的短链服务这一话题进行了讨论。笔者基于文中原理使用 Go 语言编写了一套短链服务，在性能及稳定性上都有很强的表现。目前该服务已接入多个业务，线上运行稳定，逐步取代原先的单体服务。
想要开发一款基础服务，在功能、性能和安全上都必须进行多方位考虑。文中简要提到了布隆过滤器、SnowFlake、Mysql 页分裂等技术，有兴趣的开发者们可以持续关注。
本文对短链服务设计做了详细地剖析，旨在给大家提供短链设计思路。如果你正在设计或者考虑设计一款短链服务，希望本文对你能有所帮助。
作者简介
朱陈杰，网易云商服务端开发。目前从事七鱼基础服务、云商平台开发工作，致力于云商业务、内部中间件建设。