从 0 设计一个短链接服务：如何实现尽可能短、可变长的短网址系统？

在日常生活中，我们经常在短信、微博、广告营销中看到“短链接”，如：

https://t.cn/EXaQ4xY
https://bit.ly/3Yp9zJk

相比冗长复杂的原始 URL，短链接不仅更美观、更易传播，还能用于追踪分析和跳转控制。那么问题来了：

如果你是系统设计者，如何从零构建这样一个短链接服务，满足“尽可能短、随着使用量增加再变长”的需求？

🧠 1. 问题分析：我们要解决什么？

输入一个长链接，返回一个唯一且尽可能短的短链，且短链可以反向还原长链。

系统设计核心目标：

✅ 短链接越短越好（前期尽量短，后期按需增长）
✅ 能还原原始长链接
✅ 能支持高并发、高访问量
✅ 保证唯一性、稳定性

❗提示：不能直接用 MD5、SHA1，它们生成的都是固定长度（通常32~40位）的字符串，不满足“尽量短、可变长”的要求。

💡 2. 设计思路：唯一 ID + 可变 Base62 编码

我们采用如下经典架构：

📌 方案核心：唯一 ID + Base62 编码

为每个长链接生成唯一 ID（如自增 ID、雪花算法、分布式 ID）
将 ID 编码成字符串（使用 Base62 编码：0-9a-zA-Z 共 62 个字符）
将短链和长链做持久化映射

举例：

自增 ID: 100000
编码成 Base62: q0X1
最终短链接: https://short.ly/q0X1

这种方案支持：

最初使用 6 位字符：最多 62⁶ ≈ 56 亿种组合
如果超过，则自动进位变成 7、8 位，满足“前期短，后期可扩展”的设计目标

⚙️ 3. 系统实现细节设计

① 唯一 ID 生成器

单机模式可用数据库自增主键
分布式推荐使用：
- Twitter 雪花算法（Snowflake）
- Leaf、UidGenerator
- Redis 原子自增

② Base62 编码/解码

// 将 10 进制数字转为 Base62 字符串
public static String encodeBase62(long id) {char[] chars = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray();StringBuilder sb = new StringBuilder();while (id > 0) {sb.append(chars[(int) (id % 62)]);id /= 62;}return sb.reverse().toString();
}

反向解码同理，按权展开还原为 ID。

③ 映射存储设计（短链码 ↔ 长链接）

数据库表结构：

short_code	long_url	create_time
q0X1	https://www.example.com/product/12345	2025-07-10

支持：

唯一约束（避免重复）
TTL字段（支持临时链接）
可加索引优化短链查询

④ 反查设计（可选）

如你希望同一个长链接总是生成同一个短链接（幂等），可：

对长链接做 hash（如 SHA256）
用 hash 查表，若已存在则返回已有短链

🚀 4. 扩展功能设计（更强健）

功能	实现方式说明
缓存加速访问	使用 Redis 缓存 `shortCode -> longUrl`
统计点击次数	数据库 + 缓存计数器，记录跳转事件
设置短链有效期	TTL字段 + 定期清理任务
自定义短链码	用户自定义 code，存入映射表时做唯一性校验
权限控制 / 防刷	加限流、鉴权逻辑，避免短链被猜测滥用

📊 5. 性能与可扩展性设计

场景	设计策略
高并发访问	加缓存、读写分离、加限流
存储容量扩展	短链表分表、水平分库分表
热点短链保护	本地缓存 + Redis 预热
容灾恢复	定期备份、双写数据库或异地容灾

✅ 6. 总结：一句话记住

使用唯一 ID + Base62 编码的方式，可以构建一个既短又高性能的短链接服务；通过懒增长编码长度和缓存优化等手段，满足从早期轻量到后期高并发的系统扩展需求。

采用 “唯一 ID + Base62 编码” 的方式来设计短链接系统，初期生成的短链控制在 6 位以内，最多支持 62⁶ ≈ 56 亿个链接。当量级增加后，短链长度会自动增长到 7 位、8 位，以此实现变长编码机制。所有映射关系会存入数据库，热门短链通过 Redis 缓存提速。系统支持反向解码、去重、自定义短链、TTL、点击统计等功能，具备良好的扩展性和容错能力。