相信你这辈子会收到很多短信，而这些短信有一个特点，就是链接很短。这些链接背后的基本原理是什么？如何？小编今天就带你详细了解一下

简介

相信你这辈子会收到很多短信，尤其是最近的双十一，这些短信有两个特点。首先是它们几乎都是垃圾短信，这里可以忽略。不管怎样，第二个特点就是链接很短，比如下面这样：

我们知道有些短信有字符限制。不宜直接放各种参数的链接。还有一点是我们不想暴露参数。好处不外乎以下几点：

这背后的原因是什么？如何？让你实现这样一个短链接生成系统，你会怎么设计？ 

短链接的原理

短链接展示逻辑

这里最重要的知识点是重定向，先回顾一下http的状态码：

分类含义

1**

服务器收到请求，要求请求者继续操作

2**

成功，操作成功接收并处理

3**

重定向，完成请求所需的进一步操作

4**

客户端错误，请求包含语法错误或请求无法完成

5**

服务器错误，服务器在处理请求时遇到错误

那么以 3 开头的状态码都是关于重定向的：

短链接生成系统的完整跳转过程：

1.用户访问短链接，请求到达服务器

2.服务器将短链接替换为长链接，然后返回重定向状态码301/302给浏览器

301永久重定向会导致浏览器缓存重定向地址，短链接系统会错误统计访问次数

302临时重定向可以解决时间不准确的问题，但是每次都会转换到短链接系统，服务器压力会增加。

3.浏览器得到重定向状态码和真正需要访问的地址，重定向到真正的长链接。

从下图可以看出，链接确实是通过302重定向到了一个新的地址，并且返回的header中有一个字段Location就是要重定向的地址：

如何设计短链接

肯定我们第一个想到的就是压缩，和文件压缩一样，压缩后解压恢复到原来的链接，重定向到原来的链接，可惜这样不行，你看看有没有什么压缩方法可以直接压缩这么长的号码换这么短的号码？其实不可能。就像霍夫曼树一样，它只能压缩重复字符较多的字符串，效率更高。像链接一样，参数可能很多，有各种不规则，所以直接压缩算法是不现实的。 .

这两者之间的装备是什么样的？前面路径不变，后面是tzHLFw和gmccapp/webpage/payPhonemoney/index.html?channel=的转换。

其实很简单，就是数据库中的一条数据，一个id对应一个长链接（相当于一个全球号码发送者，全球唯一ID）：

idurl

1

/gmccapp/web…

这里用到的就是我们之前提到的分布式全局唯一ID。如果我们直接用id作为参数，好像也是可以的：访问这个链接的时候，去数据库查询得到真实的url，然后重定向。

单机唯一ID很简单。你可以使用原子类 AtomicLong，但分布式的还不够。简单点，可以使用redis，或者数据库会自动增加，也可以考虑Zookeeper之类的。

id转换策略

但是直接使用递增数字有两个缺点：

显然，我们平时看到的链接不是数字，通常是大写和小写字母加数字。为了缩短链接的长度，我们必须转换id。例如，我们的短链接由 a-z、A-Z、0-9 组成，相当于一个 62 位数字。将id转换为62位数字：

public class ShortUrl {
 
    private static final String BASE = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
 
    public static String toBase62(long num) {
        StringBuilder result = new StringBuilder();
        do {
            int i = (int) (num % 62);
            result.append(BASE.charAt(i));
            num /= 62;
        } while (num > 0);
 
        return result.reverse().toString();
    }
 
    public static long toBase10(String str) {
        long result = 0;
        for (int i = 0; i < str.length(); i++) {
            result = result * 62 + BASE.indexOf(str.charAt(i));
        }
        return result;
    }
 
    public static void main(String[] args) {
        // tzHLFw
        System.out.println(toBase10("tzHLFw"));
        System.out.println(toBase62(27095455234L));
    }
}

已经实现了id到62位key或者key到id的转换，但是计算还是比较耗时的。最好添加一个字段并保存，这样数据库就变成了：

idkeyurl

27095455234

tzHLFw

/gmccapp/web…

但是还是很容易猜到id和key的对应关系。如果被遍历访问，还是很不安全的。如果不放心，可以随机打乱短链接的字符顺序，或者放在合适的位置。添加一些随机生成的字符，如第1、4、5位为随机字符，其他位置不变。只要我们在计算的时候把对应关系保存到数据库中，就可以通过连接找到对应的key。网址。 （值得注意的是key必须是全局唯一的，如果有冲突必须重新生成）

一般短链接都有过期时间，所以我们还要在数据库中添加相应的字段。访问时先判断是否过期，过期不重定向。

性能注意事项

如果暴露的短链接很多，数据库中的数据很多，这个时候可以考虑使用缓存优化。生成的时候顺便写到缓存，然后再读，就去缓存，因为一般短链接和长链接的关系是不会被修改的，而且就算修改了也是很低的频率的东西。

如果系统的 ID 用完怎么办？这个概率很小，如果真的发生了，可以重新使用已经过期的旧id号。

如果有人疯狂地要求一些不存在的短链接怎么办？其实这就是缓存穿透。缓存穿透是指大量请求缓存和数据库中不可用的数据。例如，订单号不能为-1，但用户请求大量的订单号为-1的数据。如果存在，则缓存中不存在数据，所有请求都会直接渗透到数据库中。如果被恶意用户利用，疯狂请求不存在的数据，就会导致数据库压力过大，甚至崩溃。

这种情况下，一般可以使用布隆过滤器来过滤掉不存在的数据请求，但是我们这里的id本来就是递增有序的。其实我们的范围是众所周知的最新版本:设计一个基于Java的短链接生成系统，比较容易判断。一定不存在，或者请求到达的时候，把一个空的对象放到缓存里也没问题。

以上就是关于《Java短链接生成系统设计》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器