# 面试题：短链接唯一 ID 设计这块挑战是什么？

短链接系统的核心是：

> **把一个长 URL 映射成一个短、唯一、可查询、可高并发生成的 ID。**

看似只是“生成一个短字符串”，但实际上背后是**分布式唯一 ID、冲突率控制、可扩展性、可回收性、安全性、热 Key 问题**等一整套工程挑战。

下面从工程视角解析短链接唯一 ID 的真正难点。

---

## 一、核心挑战 1：如何保证唯一性（高 QPS 下不冲突）

短链接 ID 需要：

* 全局唯一
* 碰撞概率极低
* 高并发可生成（百万 QPS）

这本质上是一个 **分布式 ID 生成问题**，挑战包括：

### 1）如果用随机生成（Base62/Hash），就有碰撞风险

例如：

```
hash(url) → 6位短码
```

6 位 Base62 大约 56 亿空间，听起来不少，但：

* 高并发下生日悖论导致碰撞概率迅速升高
* 必须一个短码只能对应一个 URL
* 一旦碰撞，需要重新生成，带来延迟波动

### 2）如果用自增 ID，要解决分布式自增难题

MySQL 的 auto_increment 不适合高 QPS
分库分表后 ID 连续性打乱，编码需要注意：

* 不同库不同起始位
* 不同节点步长跳增
* 需要全局唯一

### 3）如果使用雪花 ID（Snowflake），不能直接使用

Snowflake 生成的 ID 是 64 位数字，太长。
还要：

* 再 Base62 编码
* 控制长度（一般 6–8 位）

但雪花生成速度快、冲突率低，是业内普遍方案。

---

## 二、核心挑战 2：ID 的可读性与长度限制（用户体验 vs 空间）

短链接常要求：

* 短（通常 6–8 位）
* 可复制、不易输错
* 尽量只用 URL 安全字符

所以上述 ID 空间非常有限：

* 6 位 Base62 = 56 亿
* 7 位 Base62 = 3500 亿
* 8 位 Base62 = 218 万亿

挑战在于：

* 越短越好（用户体验）
* 越长越安全（碰撞更少）

需要权衡：

> **短链接长度 = 数据量规划 + 碰撞概率模型 + 未来增长预估**

---

## 三、核心挑战 3：多机房 / 多节点分配 ID 一致性、防重复、时钟回拨

如果采用 **Snowflake / 自研分布式 ID**，必须解决：

1）机器 ID 分配冲突（避免两个节点生成同一个序列）
2）跨机房多活场景如何分配节点号
3）时钟回拨导致 ID 重复
4）ID 递增带来的“批量热链路热点”问题

企业级系统必须有：

* **自动节点号分配（Etcd/ZK）**
* **时钟检测与回拨保护**
* **监控节点 ID 生成速率**

否则线上极易出现重复 ID 事故。

---

## 四、核心挑战 4：短链接的热 Key 问题（亿级访问热点）

短链接系统的特点是：

* 链接数量大
* 但访问分布极度不均匀（Zipf 分布）

例如：

* 一个明星发微博，短链访问量瞬间几千万
* 某个热门促销链接全民点击

挑战在于：

* 垂直热点
* 高并发读同一个 Key
* 缓存穿透转向数据库 → 数据库瞬间压垮

所以 ID 设计必须支持：

* 多级缓存（CDN → Nginx → Redis → 本地 LRU）
* 多机房读写分离
* 限流与熔断保护

**ID 本身不是热点，映射关系是热点。**

---

## 五、核心挑战 5：短码的生成方式不同会引入不同风险模型

业界常见几种方式：

#### 方式 1：随机短码（Base62 随机生成）

优点：无状态
缺点：**碰撞概率高，需要反复尝试**

#### 方式 2：雪花 ID + Base62

优点：

* 分布式生成
* 冲突概率极低
* 性能强
* 秒级生成百万 ID

缺点：

* ID 有时间相关性，可被枚举攻击（安全问题）

#### 方式 3：数据库自增 ID + Base62

优点：

* 简单可靠
* 序列严格唯一

缺点：

* 数据库单点瓶颈（需分布式序列器）

#### 方式 4：对 URL 做 Hash（MD5/SHA → Base62）

优点：

* 同 URL 多次生成同短码
* 无需存储短码 → URL 映射

缺点：

* hash 截断导致冲突概率高
* 不适合大规模场景

任何短码生成方案都有 trade-off，需要权衡。

---

## 六、核心挑战 6：短码的“可回收”与“不可回收”

业务上会出现：

* 用户创建海量一次性短链
* 有些短链过期后希望释放短码空间
* 允许短码重用吗？

如果不允许：

* 必须一直增长 → 空间有限 → 必须增加长度
* 长期可用性下降

如果允许重用：

* 需要引入 TTL、版本号、墓碑标记等
* 要保证老短链不会和新短链冲突
* 缓存过期、边缘 CDN 必须同步更新

这是一个非常复杂的工程问题。

---

## 七、核心挑战 7：短链接的安全性（被穷举攻击）

短链接容易被攻击者暴力扫描：

* 因为空间小（6 或 7 位）
* 攻击者可以逐个尝试访问
* 有可能猜中隐私数据的短链接

需要：

* 加盐
* 随机散布
* 访问鉴权
* IP/UA 限制
* 私有短链和公共短链隔离

设计 ID 的时候就要考虑安全性。

---

## 八、面试可背总结（你可以直接背）

你可以这样回答：

> “短链接的唯一 ID 设计的挑战主要包括以下几个方面：
>
> **第一，唯一性和碰撞概率控制。**
> 随机生成会碰撞，Hash 截断会碰撞，分布式自增需要解决节点号冲突；需要一个可扩展的全局 ID 体系。
>
> **第二，短码长度有限，空间有限，需要平衡体验与碰撞风险。**
> 6 位和 7 位 Base62 的容量不同，需要根据业务增长预估设置长度。
>
> **第三，分布式 ID 的一致性问题。**
> 涉及多机房、多节点 Snowflake 时间回拨、节点号冲突、ID 重复风险。
>
> **第四，热点访问。**
> 短链访问呈强 Zipf 分布，单个映射 Key 可能上亿 QPS，需要多级缓存与读扩散方案。
>
> **第五，回收与重用机制。**
> 是否允许过期短码被回收？如何避免历史短链被重新指向？
>
> **第六，安全性。**
> 短码易被穷举，需要加入随机盐、加密、鉴权等策略。”
>
> “短链接的唯一 ID 之所以难，是因为它涉及分布式 ID、碰撞概率控制、短码空间规划、缓存结构、热 Key 控制、安全模型等多个工程挑战，而不仅仅是‘生成一个短字符串’。”