在大厂面试中，面试题：如何设计一个短链接生成系统是考察分布式系统设计能力的经典题目。这类系统需将冗长的URL压缩为6-8位的短码，同时支撑高并发生成（如峰值QPS 10万+）、低延迟跳转（<100ms）和精准的点击统计，核心挑战在于短码唯一性保证、哈希冲突解决与高可用架构设计。本文将从需求分析、核心算法、架构设计到实战优化，全面拆解短链接系统的设计要点，结合真实案例与技术选型，帮你在面试中展现从业务到底层的全链路设计能力，正如鳄鱼java在《分布式系统设计实战》中强调的："短链接系统的本质，是在极小的空间内实现极高的可用性与扩展性。"
需求分析：短链接系统的核心功能与技术指标
设计短链接系统需先明确业务场景与技术边界，避免过度设计或功能缺失。
1. 核心功能需求
- 短链接生成：将长URL转换为唯一短码（如
https://t.cn/abcd12），支持自定义短码、有效期设置 - 跳转服务：用户访问短链接时，302重定向至原始长URL
- 数据统计：记录点击量、访问来源（设备/地区/浏览器）、跳转耗时等 metrics
- 管理后台：短链接创建、编辑、禁用，统计数据可视化
某社交平台数据显示：短链接平均使内容排版效率提升40%，二维码识别成功率提高25%，尤其在短信、微博等字数受限场景中不可或缺。
2. 非功能需求与技术指标
| 指标类型 | 具体要求 | 技术挑战 |
|---|---|---|
| 性能 | 生成QPS 1万+，跳转响应时间<100ms | 高并发写入与读取优化 |
| 可用性 | 系统可用性99.99%，短码永久有效（除非主动删除） | 数据持久化与容灾设计 |
| 唯一性 | 短码全局唯一，无冲突 | 分布式ID生成与哈希冲突解决 |
| 安全性 | 防恶意生成、防盗刷、防跳转钓鱼链接 | 访问频率限制与内容审核 |
核心技术：短码生成算法与冲突解决
短码生成是系统的核心，需在保证唯一性的同时，兼顾生成效率与短码长度。
1. 短码生成算法对比与选型
常见短码生成方案各有优劣，需根据业务场景选择：
- 哈希算法（推荐）：
- 原理：对长URL进行哈希计算，取哈希值的后n位转为62进制（a-z/A-Z/0-9）
- 推荐算法：MurmurHash3（非加密哈希，性能是MD5的10倍以上，随机分布性好）
- 短码长度：6位62进制可提供62^6=568亿种组合，满足千万级用户需求
- 案例：
长URL → MurmurHash3-32 → 十进制哈希值 → 62进制转换 → 6位短码 - 自增ID算法： - 原理：使用分布式ID生成器（如Snowflake）生成自增ID，再转为62进制 - 优势：绝对无冲突，短码有序增长 - 劣势：暴露系统增长规模，存在安全风险（可猜测后续短码）
- 随机字符串算法： - 原理：随机生成6位62进制字符串，检查数据库是否存在冲突 - 优势：实现简单 - 劣势：高并发下冲突概率高，需多次重试（10万QPS下冲突率约0.1%）
鳄鱼java技术团队实测显示：在千万级URL场景下，MurmurHash3+62进制转换方案的冲突率<0.001%，性能比自增ID方案高30%。
2. 哈希冲突解决策略
即使使用优秀的哈希算法，仍可能出现冲突，需通过以下机制解决：
- 冲突检测：生成短码后查询数据库，若已存在则触发冲突处理
- 冲突处理：
- 方案1：在长URL后添加随机字符串（如
URL+随机数）重新哈希 - 方案2：使用双重哈希（如同时计算MurmurHash和FNV哈希，取不同位数组合） - 方案3：维护冲突映射表，对冲突短码添加固定前缀（如s-xxxxxx）
// 冲突处理伪代码
String generateShortCode(String longUrl) {
while (true) {
String hash = murmurHash3(longUrl);
String shortCode = toBase62(hash).substring(0, 6);
if (!db.exists(shortCode)) {
return shortCode;
}
// 冲突时添加随机数重试
longUrl += RandomUtils.nextInt(1000);
}
}
架构设计：高并发与高可用的分层架构
短链接系统需支撑高并发写入（生成）与超高并发读取（跳转），需采用分层架构设计。
1. 整体架构图与核心组件
用户 → CDN → 负载均衡 → 接入层（Nginx/API网关）
↓
应用层 → 短码生成服务、跳转服务、统计分析服务
↓
数据层 → Redis集群（缓存短码-URL映射）、MySQL（持久化存储）、Kafka（异步统计）
关键设计原则： - 读写分离：生成服务（写）与跳转服务（读）独立部署，读服务可水平扩容 - 多级缓存：CDN缓存→接入层本地缓存→Redis集群，将跳转请求命中率提升至99% - 异步化：点击统计、日志记录等非核心流程通过Kafka异步处理，不阻塞主流程
2. 核心服务设计细节
- 短码生成服务： - 无状态设计，支持水平扩容 - 批量预生成短码池（如提前生成100万短码存入Redis，生成时直接弹出，减少数据库访问） - 接口限流：单IP每分钟最多生成100个短码，防止恶意请求
- 跳转服务：
- 核心逻辑：
短码 → Redis查询 → 302重定向，全程无数据库访问 - 重定向选择：302临时重定向（支持统计点击量），而非301永久重定向（浏览器会缓存，导致统计不准） - 降级策略：Redis故障时，返回默认页面或直接跳转错误页，避免级联失败
存储设计：缓存与数据库的协同策略
短链接系统的存储需平衡性能与成本，采用"缓存为主、数据库为辅"的策略。
1. Redis缓存设计
Redis作为跳转服务的核心，需优化key设计与过期策略：
- Key设计：short:{shortCode} → longUrl，如
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
