最通俗易懂的短链接原理讲解

看业务代码的时候，有些逻辑用到了短链接服务，感觉还蛮有意思的，这里简单的记录一下。

这种营销短信大家应该都收到过，短信有最大字符限制，而且为了更好的观感体验，短信里的链接一般都很短。现成的短链接生成服务也比较多，比如新浪、百度等，谷歌之前也有短链接服务，号称是最快的，但是在 2018 年关闭了。

一、短链接原理

我们点击短链接会发起一个 GET 方式的 HTTP 请求，当请求到对应的 API 后，会解析短链接里的标识获取到对应的长链接，然后重定向到长链接，这样整个流程就结束了。

比如我用新浪的短链接服务为 https://www.google.com/ 生成了一个短链接：http://dwz.date/evn，下面是请求短链接时对应的 HTTP 信息：

二、短链接生成算法

短链接标识一般是 [0-9, a-z, A-Z] 随机组合而成的字符串，字符一共有 62 个，因此短链接标识可以用 62 进制的字符串表示。

首先维护一个自增的 ID，当生成短链接时，将 10 进制的自增 ID 转换成 62 进制字符串，这个字符串就可以唯一标识一个长链接。由于 ID 是自增的，对应的 62 进制字符串是不同的，这样就不会出现一个短链接对应多个长链接的问题，62 个字符排列组合，可以保证短链接是用不完的，就算仅限于 6 位长度标识的短链接，也有 558 亿多种情况，这种算法在网上被称为自增序列算法。

维护自增 ID 主要有以下几种方式：

1. 数据库主键自增
2. redis 自增
3. 分布式自增主键 ID（雪花算法，存在 ID 浪费）

下面是 62 进制的 encode 与 decode 方法，来自 Base62。

    private static String base62(Long b10) {
        StringBuilder ret = new StringBuilder();
        while (b10 > 0) {
            ret.insert(0, characters.charAt((int) (b10 % 62)));
            b10 /= 62;
        }
        return ret.toString();
    }

    private static long decodeBase62(String b62) {
        long ret = 0;
        b62 = new StringBuffer(b62).reverse().toString();
        long count = 1;
        for (char character : b62.toCharArray()) {
            ret += characters.indexOf(character) * count;
            count *= 62;
        }
        return ret;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

三、一些细节

1. 自增序列算法也存在一定的缺点，当自增主键很大时，生成的 62 进制字符串会变长，以 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ 顺序的 62 进制为例，当主键大于 56800235583 时，会生成 7 位长度的 62 进制字符串。这个问题可以通过控制自增主键的增长速度来解决，而且要避免主键浪费。
2. 62 进制的顺序并不一定严格按照 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ 的顺序来表示，这个顺序可以是打乱的，这样生成的短链接标识更随机不易被破解。
3. 长链接与短链接是否需要一对多关系，同一个长链接使用自增主键 ID 算法生成的短链接是不同的，因为自增主键 ID 不同，生成的 62 进制字符串自然也不同。如果我们有一个长链接唯一对应一个短链接需求，可以将长链接进行 md5 加密，将加密后的 md5 值存储在 DB 中，每次生成短链接前都根据长链接 md5 值查询 DB，如果存在，则直接返回短链接，当然也可以使用其他方式维护这种关系。
4. 跳转用 301 还是 302，301 永久重定向，302 是临时重定向。短地址一经生成就不会变化，所以用 301 是符合 http 语义的。同时对服务器压力也会有一定减少。
   但是如果使用了 301，我们就无法统计到短地址被点击的次数了。而这个点击次数是一个非常有意思的大数据分析数据源。能够分析出的东西非常非常多。所以选择 302 虽然会增加服务器压力，但是我想是一个更好的选择。from 短 URL 系统是怎么设计的？ by iammutex
5. 如果短链接请求频繁，可以借助 redis 做对应的缓存优化。

PS：做一次标题党，师承 SCDN 官方