今天我们来聊一聊短链接系统。

很多人第一次接触短链时，会误以为它是用来“削峰限流”的，
但实际上，这是一种常见误解。

假设一个热门活动链接在一瞬间有百万请求访问：

https://chatgpt.com/jasdlfkjkkldfsaklsafdasdfSADFADSG

即使我们引入短链：

https://short.ly/aZ91k

用户访问流程变成：

用户 → 短链服务 → 重定向 → 原始链接

可以看到，请求并没有减少，反而多了一次跳转，
因此短链系统本身并不能减少流量压力。

那么短链真正的作用是什么？

1. 将长 URL 压缩为短码，提升传播体验
2. 作为统一跳转入口，实现访问统计
3. 支持动态修改跳转地址
4. 隐藏原始参数，提高安全性

接下来，我们再来看短链系统是如何实现的。

在学这个系统之前，我们应该提前学习过Redis、本地缓存、消息队列等简单的基础知识了。

首先我先接受一个算法《Base62》

private static final char[] ALPHABET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".toCharArray();

简单来说就是将0-9、a-z、A-Z 一共62个字符组成的算法
比如原来的id为123456789循环除以62之后，得到的编码是8m0Kx（反转，适应62进制）
这样看可能还是都不太理解如果一个链接是这样的呢

https://www.like.com/order/detail?id=123456789&from=app&user=9988...

被Base62之后就变成了

https://short.ly/aZ91k

这样是不是就变得好多了
那么它的作用是什么呢？
比如你给别人发一个短信，你点击了一下之后跳转到了一个网址，如果刚开始就给你发了

https://www.like.com/order/detail?id=123456789&from=app&user=9988...

• 是不是看着非常不美观。
• 其次就是所有参数都暴露在上面，也不安全。

将其短链后再重定向，就可以解决这类问题了。

那有人可能问这些问题。

为什么不用 Base64？

• 有 + / = 不适合 URL

Base62 会冲突吗？

• 只要输入的 ID（如 Snowflake）是唯一的，
  则编码结果也是唯一的

 ID 很长怎么办？

• Base62 已经是压缩后的最优方案之一

明天我们继续来讲后续的实现。