一、为什么需要短链接

二、使用短链接的一些典型场景

2.1 字数限制场景

2.1.1 微博内容

2.1.2 用户短信

2.2 短链接二维码

2.3 无法识别长链接场景

三、短链接生成方案

四、短链接如何跳转

五、短链接服务优化

5.1、算法优化

5.2、可伸缩和高可用

六、如何用代码实现短地址

1、使用数值放号器生成短地址

2、使用随机序列生成短地址

七、短链接服务提供平台

八、总结

一、为什么需要短链接

所谓短链接，就是将长链接网址缩短到一个很短的网址，用户访问这个短网址时，可以重定向到原来的长链接网址。

这样可以达到易于记忆、方便使用、节省资费的目的，常用于有字数限制的微博、二维码等场景。

使用短链接的好处：

（1）节省网址长度，便于社交化传播。短链接URL更短小，传播更方便。尤其是URL中有中文和特殊字符时，短网址解决了长链接URL难以记忆、不利于传播的问题。当你看到一个淘宝的购物链接后面是200个“e7x8bv7c8bisdj”这样的字符的时候，肯定会觉得不舒服。

（2）方便对URL进行管理。有一部分网址可能会涵盖性、暴力、广告等信息，这时我们可以通过用户的举报，完全管理这个链接，使之不出现在我们的应用中。

（3）方便后台跟踪点击量、地域分布等用户统计。我们可以对一系列的网址进行流量、点击量等统计，挖掘出大多数用户的关注点，这有利于我们对项目的后续工作更好地作出决策。

（4）规避关键词、域名屏蔽手段、隐藏真实地址，适合做付费推广链接。

二、使用短链接的一些典型场景

2.1 字数限制场景

2.1.1 微博内容

我们在新浪微博上发布的内容包含长链接网址的时候，微博服务会自动判别出长链接网址，并将其转换为短链接网址。

这是因为新浪微博限制字数为140字一条。如果我们需要发布的内容包含一些链接，但是这些链接非常长，以至于要占用我们内容的一半篇幅、甚至更多，这肯定是不能被允许的，或者说用户体验很差的。此时，就需要将内容里的长链接地址替换为短链接地址。

2.1.2 用户短信

一般短信发文有长度限度。如果使用长链接地址，那么一条短信很可能要拆分成两三条发，本来一条一毛的短信费变成了两三毛，直接提升了几倍的花费。另外，使用短链接在内容排版上也更为美观。

2.2 短链接二维码

二维码核心解决的是跨平台、跨现实的数据传输问题，我们经常需要将链接转成二维码的形式分享给他人。使用长链接网址生成的二维码，码点密集复杂，难以识别。使用短链接生成的二维码，码点稀疏清晰，就不存在这个问题了。

2.3 无法识别长链接场景

在有些平台上，长链接地址无法自动识别为完整的超链接，只能识别一部分url地址，甚至根本无法识别。譬如，在钉钉、企微上，长链接地址通常只能被识别一部分，而不是完整的链接地址。

三、短链接生成方案

关于短链接URL的生成方式，网上有很多方法。有基于映射的，有基于Hash的，有基于签名的，但是总的来说，并不能满足绝大部分场景的使用，或者说是一种错误的设计方式。这里不再重复造轮子，而是使用一种业界成熟的方案：通过放号器的方式生成短链接。

通过放号器的方式生成短链接，算法设计要点如下：

（1）生成短路径PATH：利用放号器，初始值为0，对于每一个短链接生成请求，都递增放号器的值，再将此值转换为62进制（a-zA-Z0-9），这个62进制值即为短URI。比如第一次请求时放号器的值为0，对应62进制为a，第二次请求时放号器的值为1，对应62进制为b，第10001次请求时放号器的值为10000，对应62进制为sBc。

（2）短链接服务域名与短URL PATH拼接：将短链接服务器域名与短路径PATH进行字符串连接，即为短链接的URL，比如：t.cn/sBc。

（3）重定向过程：生成短链接之后，需要存储短链接到长链接的映射关系，即短链接 -> 长链接；浏览器访问短链接服务器时，从短链服务器取到原始的长链接，然后进行302重定向。映射关系可使用K-V存储，比如Redis或Memcache。

放号器生成的ID即为短链接ID。为什么要选用62进制转换短链接ID？62进制数的6次方为568亿，即6位62进制数可表示568亿的数，可大幅减小短路径PATH的长度。

可以参考知乎上大神给出的讨论：https://www.zhihu.com/question/29270034/answer/46446911

四、短链接如何跳转

浏览器在请求访问短链接时，会从短链接服务器获取到长链接地址，然后重定向访问长链接地址。

以短链接地址为http://t.cn/RuPKzRW、对应的长链接地址为https://blog.csdn.net/xlgen157387/article/details/79863301为例，在访问短链接时，具体交互的流程为：

（1）用户访问短链接：http://t.cn/RuPKzRW。

（2）短链接服务器t.cn收到请求，根据URI路径RuPKzRW获取到原始的长链接（KV缓存数据库中去查找）：https://blog.csdn.net/xlgen157387/article/details/79863301。

（3）短链接服务器返回302状态码，将响应头中的Location设置为长链接：https://blog.csdn.net/xlgen157387/article/details/79863301。

（4）浏览器重新向https://blog.csdn.net/xlgen157387/article/details/79863301发送请求。

（5）业务服务器返回响应。

这里有个问题：301和302都是重定向，到底该用哪个？需要注意一下301和302的区别。

301，表示永久重定向。也就是说，第一次请求拿到长链接后，下次浏览器再去请求短链的话，不会向短网址服务器请求了，而是直接从浏览器的缓存里拿，这样在 server 层面就无法获取到短网址的点击数了。如果这个链接刚好是某个活动的链接，也就无法分析此活动的效果。所以，我们一般不采用301。
302，表示临时重定向。也就是说，每次去访问短链接，都会去请求短链接服务器（除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存），这样就便于server统计点击数。所以，虽然用 302 会给 server 增加一点压力，但在数据非常重要的今天，这是值得的，推荐使用302！

五、短链接服务优化

5.1、算法优化

以上算法存在一个问题：对于同一个原始URL，每次生成的短链接是不同的，这样就会浪费存储空间（因为需要存储多个短链接到同一个URL的映射）。如果能将相同的URL映射成同一个短链接，这样就可以节省存储空间了。主要的思路有如下两个：

方案1：查表

放号器生成的ID即为短链接ID。每次生成短链接时，先在映射表中查找是否已有原始URL的映射关系。如果给原始长链接加索引，那么索引的空间会很大，所以我们可以对长链适当的压缩，比如md5，再对长链接的md5值做索引，索引就会小很多。这样，只要根据长链接的md5值去查询是否存在相同的记录即可。如果数据量很大，则需要分区或分库分表。记录短链接与长链接映射关系的表结构为：

CREATE TABLE `short_url_map` (`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT'自增id',`post_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT'短链接id',`url` varchar(1000) DEFAULT NULL COMMENT'长链',`md5` char(32) DEFAULT NULL COMMENT'长链md5',`gmt_create` bigint(20) DEFAULT NULL COMMENT'创建时间',PRIMARY KEY (`id`),UNIQUE KEY `uq_post_id` (`post_id`),KEY `idx_md5` (`md5`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

方案2：使用LRU本地缓存，空间换时间

使用固定大小的LRU缓存，存储最近N次的映射结果。这样，如果某一个链接生成的非常频繁，则可以在LRU缓存中找到结果直接返回。这是存储空间和性能方面的折中。

5.2、可伸缩和高可用

如果将短链接生成服务单机部署，缺点一是性能不足，不足以承受海量的并发访问；缺点二是成为系统单点。如果这台机器宕机，则整套服务不可用。为了解决这个问题，可以将系统集群化，进行“分片”。

在以上描述的系统架构中，如果放号器用Redis实现，则Redis是系统的瓶颈与单点。因此，利用数据库分片的设计思想，部署多个发号器实例，每个实例负责特定号段的发号，比如部署10台Redis，每台分别负责号段尾号为0-9的发号，注意此时发号器的步长应该设置为10（实例个数）。

另外，也可将长链接与短链接映射关系的存储进行分片。由于没有一个中心化的存储位置，因此需要开发额外的服务，用于查找短链接对应的原始链接的存储节点，这样才能去正确的节点上找到映射关系。

六、如何用代码实现短地址

1、使用数值放号器生成短地址

对于使用SnowFlake算法或自增ID序列算法生成的短链接ID，生成短路径PATH的方法是一样的。

下面，以使用SnowFlake算法生成的短链接ID为例进行讲解。

Twitter开源的雪花算法SnowFlake，使用Java语言实现。

SnowFlake算法用来生成64位的ID，刚好可以用long整型存储，能够用于分布式系统中生产唯一的ID，并且生成的ID有递增的顺序。在这次实现中，生成的64位ID可以分成5个部分：

0固定值 - 41位时间戳 - 5位数据中心标识 - 5位机器标识 - 12位序列号

5位数据中心标识、5位机器标识，这样的分配仅仅是当前实现中分配的。如果业务有其他需要，可以按其它的比例分配，例如10位机器标识，不需要数据中心标识。

进制转换工具的Java代码实现：

/*** 进制转换工具，最大支持十进制和62进制的转换* 1、将十进制的数字转换为指定进制的字符串* 2、将其它进制的数字（字符串形式）转换为十进制的数字*/
public class NumericConvertUtils {/*** 在进制表示中的字符集合，0-Z分别用于表示最大为62进制的符号表示*/private static final char[] digits = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm','n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z','A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M','N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z','0', '1', '2', '3', '4', '5', '6', '7', '8', '9'};/*** 将十进制的数字转换为指定进制的字符串* @param number 十进制的数字* @param seed   指定的进制* @return 指定进制的字符串*/public static String toOtherNumberSystem(long number, int seed) {if (number < 0) {number = ((long) 2 * 0x7fffffff) + number + 2;}char[] buf = new char[32];int charPos = 32;while ((number / seed) > 0) {buf[--charPos] = digits[(int) (number % seed)];number /= seed;}buf[--charPos] = digits[(int) (number % seed)];return new String(buf, charPos, (32 - charPos));}/*** 将其它进制的数字（字符串形式）转换为十进制的数字* @param number 其它进制的数字（字符串形式）* @param seed   指定的进制，也就是参数str的原始进制* @return 十进制的数字*/public static long toDecimalNumber(String number, int seed) {char[] charBuf = number.toCharArray();if (seed == 10) {return Long.parseLong(number);}long result = 0, base = 1;for (int i = charBuf.length - 1; i >= 0; i--) {int index = 0;for (int j = 0, length = digits.length; j < length; j++) {//找到对应字符的下标，对应的下标才是具体的数值if (digits[j] == charBuf[i]) {index = j;}}result += index * base;base *= seed;}return result;}
}

SnowFlake算法的Java代码实现：

/*** 使用SnowFlake算法生成一个整数，然后转化为62进制，变成一个短地址URL的PATH*/
public class SnowFlakeShortUrl {/*** 起始的时间戳*/private final static long START_TIMESTAMP = 1480166465631L;/*** 每一部分占用的位数*/private final static long SEQUENCE_BIT = 12;   //序列号占用的位数private final static long MACHINE_BIT = 5;     //机器标识占用的位数private final static long DATA_CENTER_BIT = 5; //数据中心占用的位数/*** 每一部分的最大值*/private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);/*** 每一部分向左的位移*/private final static long MACHINE_LEFT = SEQUENCE_BIT;private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;private long dataCenterId;  //数据中心private long machineId;     //机器标识private long sequence = 0L; //序列号private long lastTimeStamp = -1L;  //上一次时间戳/*** 根据指定的数据中心ID和机器标志ID生成指定的序列号* @param dataCenterId 数据中心ID* @param machineId    机器标志ID*/public SnowFlake(long dataCenterId, long machineId) {if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");}if (machineId > MAX_MACHINE_NUM || machineId < 0) {throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");}this.dataCenterId = dataCenterId;this.machineId = machineId;}/*** 产生下一个ID* @return*/public synchronized long nextId() {long currTimeStamp = getNewTimeStamp();if (currTimeStamp < lastTimeStamp) {throw new RuntimeException("Clock moved backwards.  Refusing to generate id");}if (currTimeStamp == lastTimeStamp) {//相同毫秒内，序列号自增sequence = (sequence + 1) & MAX_SEQUENCE;//同一毫秒的序列数已经达到最大if (sequence == 0L) {currTimeStamp = getNextMill();}} else {//不同毫秒内，序列号置为0sequence = 0L;}lastTimeStamp = currTimeStamp;return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //时间戳部分| dataCenterId << DATA_CENTER_LEFT       //数据中心部分| machineId << MACHINE_LEFT             //机器标识部分| sequence;                             //序列号部分}private long getNextMill() {long mill = getNewTimeStamp();while (mill <= lastTimeStamp) {mill = getNewTimeStamp();}return mill;}private long getNewTimeStamp() {return System.currentTimeMillis();}public static void main(String[] args) {SnowFlake snowFlake = new SnowFlake(2, 3);for (int i = 0; i < (1 << 4); i++) {//10进制Long id = snowFlake.nextId();//62进制String convertedNumStr = NumericConvertUtils.toOtherNumberSystem(id, 62);//10进制转化为62进制System.out.println("10进制：" + id + "  62进制:" + convertedNumStr);//TODO 执行具体的存储操作，可以存放在Redis等中//62进制转化为10进制System.out.println("62进制：" + convertedNumStr + "  10进制:" + NumericConvertUtils.toDecimalNumber(convertedNumStr, 62));System.out.println();}}
}

2、使用随机序列生成短地址

如果对使用随机序列生成短地址感兴趣，这里给出一个还算可以的实现短地址的开源项目：urlshorter，项目地址：https://gitee.com/tinyframework/urlshorter。

注意：urlshorter本身还是基于随机的方式生成短地址的，并不算是一个短地址发号器，因此会有性能问题和冲突的出现！

七、短链接服务提供平台

目前，国内有很多提供短链接服务的平台，例如：

新浪：http://sina.lt/
百度：http://dwz.cn/
0x3：http://0x3.me/
MRW：http://mrw.so/

需要注意的是，如果使用某一个平台的短地址服务，一定要保证长期可靠的服务，不然一段时间失效了，我们以前转换得到的短链接地址就没法访问了！

八、总结

到此为止，我们一起学习了什么是短地址，短地址有哪些优点，如何选择一种正确的方式来实现短链接服务。抛砖引玉，希望有同学提出更好的短链接解决方案。

参考文章：

1、https://blog.csdn.net/lz0426001/article/details/52370177

2、https://blog.csdn.net/u013474436/article/details/105027065

3、https://www.zhihu.com/question/29270034/answer/46446911

4、https://xuliugen.blog.csdn.net/article/details/80026452

短链接服务架构设计概览相关推荐

.net core实践系列之短信服务-架构设计
前言上篇<.net core实践系列之短信服务-为什么选择.net core(开篇)>简单的介绍了(水了一篇).net core.这次针对短信服务的架构设计和技术栈的简析. 源码地址:h ...
.net core实践系列之短信服务-架构优化
前言通过前面的几篇文章,讲解了一个短信服务的架构设计与实现.然而初始方案并非100%完美的,我们仍可以对该架构做一些优化与调整. 同时我也希望通过这篇文章与大家分享一下,我的架构设计理念. 源码地址 ...
播放器/短视频 SDK 架构设计，点播服务 (Demo)
在Android中,我们可以直接使用MediaRecord来进行录像,但是在很多适合MediaRecord并不能满足我们的需求,比如我们需要对录制的视频加水印或者其他处理后,所有的平台都按照同一的大小 ...
短链接服务Octopus的实现与源码开放
前提半年前(2020-06)左右,疫情触底反弹,公司的业务量不断提升,运营部门为了方便短信.模板消息推送等渠道的投放,提出了一个把长链接压缩为短链接的功能需求.当时为了快速推广,使用了一些比较知名的 ...
你必须了解的微服务架构设计的10个要点！
近来,几乎人人都在谈论微服务.微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境等.本文将介绍微服务架构设计中的一些要点. 微服务架构设计时有哪些要点 ...
微服务架构设计总结实践
- 目录 - 一.微服务架构介绍二.出现和发展三.传统开发模式和微服务的区别四.微服务的具体特征五.SOA和微服务的区别六.如何具体实践微服务七.常见的微服务设计模式和应用 ...
（转）微服务架构互联网保险O2O平台微服务架构设计
http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构互联网保险O2O平台微服务架构设计关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也 ...
php 余额冻结设计_加密货币交易所：微服务架构设计
本文介绍一个实际开发并上线的加密货币交易所项目的逻辑架构设计,其中包括撮合服务.做市服务.用户服务.市场数据服务.钱包服务.报表服务等核心组件,并采用了基于AKKA集群的微服务架构. 加密交易所的逻辑 ...
百度谷歌 Twitter，这么多短链接服务（Short Url）到底哪家强？
一.短链接是什么短链接,通俗来说,就是将长的URL网址,通过程序计算等方式,转换为简短的网址字符串. 它的原理也非常简单,就是采用 Domain Redirect(域名重定向) ,将一个域名自动跳转 ...

短链接服务架构设计概览

一、为什么需要短链接

二、使用短链接的一些典型场景

2.1 字数限制场景

2.1.1 微博内容

2.1.2 用户短信

2.2 短链接二维码

2.3 无法识别长链接场景

三、短链接生成方案

四、短链接如何跳转

五、短链接服务优化

5.1、算法优化

5.2、可伸缩和高可用

六、如何用代码实现短地址

1、使用数值放号器生成短地址

2、使用随机序列生成短地址

七、短链接服务提供平台

八、总结

短链接服务架构设计概览相关推荐

最新文章

热门文章