短链系统设计#

流程：

1. 生成：长URL → 全局ID/哈希 → Base62 编码 → 存储映射
2. 访问：短码 → 查 Redis/DB → 302 重定向

核心问题：

• 唯一性：自增ID+Base62（推荐）或 MurmurHash+冲突处理
• 性能：Redis 缓存热门短链
• 过期：TTL 定期清理

短链系统的核心是把长URL映射成6位短码然后做重定向。生成短码主流两种方案：一是用分布式自增ID比如雪花算法生成全局唯一数字，再做Base62编码，6位Base62能表示约560亿种组合完全够用；二是对长URL做MurmurHash取前几位，但需要处理哈希冲突，可以用布隆过滤器做判重。存储上用MySQL存长短链映射关系，Redis缓存热门短链提升查询性能。用户访问时，短码先查Redis再查DB，找到原始URL后做302临时重定向，用302而不是301是因为301会被浏览器永久缓存导致无法统计点击量。过期短链通过TTL加定时任务清理。整体架构就是接入层Nginx做负载均衡，服务层处理编码和查询逻辑，数据层MySQL加Redis，日访问量大的话可以按短码前缀做分库分表。

追问方向：

• “用 301 还是 302 重定向？为什么？”→ 用 302 临时重定向，浏览器每次都请求短链服务，方便统计点击次数和做访问分析；301 永久重定向会被浏览器缓存，后续访问不再经过服务端无法统计
• “短码冲突怎么处理？”→ 自增 ID 方案天然无冲突；哈希方案冲突时用布隆过滤器快速判重，冲突则在原 URL 后拼接随机串重新哈希，直到不冲突为止
• “过期短链怎么清理？”→ Redis 缓存设 TTL 自动过期；DB 中通过定时任务扫描过期时间字段批量删除或标记失效，释放短码可复用

易错点：

• ❌ “用 MD5 截取就不会冲突”——哈希碰撞难以避免，需要碰撞处理机制
• ❌ “短链越短越好”——6 位 Base62 = 560 亿种组合，已经足够