核心业务流程短链系统的核心任务是将一个长的 URL 转换为一个短的 URL并在用户访问短链时快速、准确地重定向到原始链接短链系统的核心只有两个动作生成短链和重定向访问生成短链长变短长链接→\rightarrow→系统校验并转换为短链接→\rightarrow→存入数据库→\rightarrow→返回给用户重定向访问短变长用户点击短链→\rightarrow→服务端解析短链→\rightarrow→查表找到长链→\rightarrow→通过 301/302 状态码 重定向到目标网站选择301重定向还是302重定向301 (永久重定向)浏览器会缓存该关系下次访问直接走浏览器缓存减轻短链服务器压力。缺点是无法精确统计每一次的点击数据如 PV/UV302 (临时重定向)每次访问都会经过短链服务器方便收集分析数据地理位置、点击量等。缺点是服务器压力大为了减轻服务器压力选择301方便数据分析选择302表可以定义为如下字段类型说明short_codevarchar(8)短链码如 abc123long_urltext原始长 URLcreated_atdatetime创建时间核心算法如何将长链变短方案一哈希算法如 MurmurHash 冲突解决原理使用高性能、低碰撞的 MurmurHash 算法对长链进行哈希得到一个 32 位的整数再将其转化为 62 进制的 6 位字符串。冲突处理哈希必然存在碰撞。如果算出的短链在 DB 中已存在且长链不同就在长链后面拼接一个固定的“随机盐值”重新计算哈希直到不冲突为止。优缺点实现简单URL 看起来很随机但随着数据量增大碰撞概率增加检测冲突的 DB 查询开销会变大。注意在发生哈希冲突的时候虽然会在长URL后面加随机盐值重新计算哈希值但是最终存到数据库中的长URL并不会有盐值方案二分布式自增 ID 62 进制转换推荐原理这是最常用的方案。系统维护一个全局自增的分布式 ID如 10001、10002每来一个长链就分给他一个 ID然后把这个 10 进制的 ID 转换成 62 进制字符串。例如ID 568002355 转换为 62 进制后可能就是 Xy7Z8a。优缺点绝对不会冲突效率极高但缺点是短链是递增的容易被别人猜出规律并恶意爬取。解决递增被猜到的办法在 62 进制转换后利用固定的位移或混淆矩阵Shuffle将字符串顺序打乱。系统架构设计为了支撑海量高并发的访问短链系统必须采用分层架构。1. 接入层 (API Gateway / Load Balancer)Nginx / Gateway负责负载均衡限流防止恶意刷接口导致系统瘫痪。2. 逻辑服务层短链生成服务负责接收长链获取全局 ID转换成 62 进制并写入存储。短链重定向服务负责接收短链请求查询缓存/DB返回 302 重定向。这两块业务要读写分离因为读的并发量通常远大于写。3. 全局发号器 (针对分布式自增 ID 方案)如果所有服务都去数据库申请自增 ID数据库会成为瓶颈。优化方案号段模式发号器服务每次去数据库“批发”一批 ID比如一次拿 10000 个缓存在内存中。当短链服务来申请时直接在内存中自增分发。内存发完了再去数据库拿下一个号段。即便数据库挂了号段没用完前系统依然能正常工作。4. 存储与缓存层 (核心)由于短链系统是典型的 读多写少 场景缓存是抗住高并发的关键。数据库可用关系型MySQL/PostgreSQL或 NoSQLRedis 持久化 DB。缓存热点短码用 Redis 缓存 short_code, long_url降低 DB 压力本地缓存 (Guava/Caffeine) 分布式缓存 (Redis)使用 Redis 存储 短链 - 长链 的映射设置合理的过期时间。采用 布隆过滤器 (Bloom Filter)用户访问不存在的短链时布隆过滤器可以直接拦截防止缓存穿透击垮数据库。底层数据库使用 MySQL 或 NoSQL如 MongoDB/HBase。因为主要是 KV 查询NoSQL 表现更好。如果用 MySQL需要对 短链码 字段建立唯一索引。当数据量极大时按短链码的 Hash 进行分库分表。系统设计实战每天有1000w条数据需要生成短链需要保存3年1. 容量和性能评估A. 存储容量计算每日新增1,000 万条。保存时间3 年 3 × 365 1,095 天。总数据量1,000 万 × 1,095 ≈ 110 亿条数据单条数据大小估计字段长度id (Long)8 字节short_code (String, 6-8位)8 字节long_url (String, 假设平均100字符)100 字节create_time (Datetime):8 字节加上索引开销单条数据约 200 字节。总存储空间110 亿 × 200 字节 ≈ 2.2 TB不含数据库副本/主从备份。B. 吞吐量 (QPS) 预估写 QPS (生成短链)平均写 QPS 10,000,000 ÷ 86400 秒 ≈ 116 QPS峰值写 QPS (按 5 倍计) ≈ 600 QPS写压力其实并不大读 QPS (重定向)互联网电商/营销场景下读写比通常在 10:1 到 100:1 之间。假设读写比为 50:1平均读 QPS ≈ 6,000 QPS峰值读 QPS ≈ 30,000 QPS读是核心瓶颈2. 核心算法与短链长度选型为了抗住 110 亿的数据规模且保证绝对不冲突、不被猜出规律必须选择“分布式自增 ID 位移/矩阵混淆”的方案短链长度选择62 进制下6 位长度可容纳626≈568亿62^6 \approx 568 亿626≈568亿条数据7 位可容纳 3.5 万亿条。我们的目标是 110 亿因此 6 位短链码 刚好完美覆盖且留有充足余量3. 工业级数据存储与分库分表设计110 亿数据、2.2 TB 存储单表 MySQL 绝对无法支撑MySQL 单表建议不超过 2000 万条数据。 我们需要做数据分片Sharding方案一MySQL 分库分表由于短链系统的查询极其单一100% 都是拿着 short_code 查 long_url是非常完美的 KV 结构。分片键 (Sharding Key)选择 short_code 作为分片键。分表数量总数据 110 亿若让单表保持在 1000 万条的最佳性能状态整个系统需要110亿÷1000万1100110亿 \div 1000万 1100110亿÷1000万1100张表。我们可以规划 16 个数据库实例每个库含 64 张表总共 1024 张表。路由逻辑用户带上短链码 e9Xb3q 访问。系统通过混淆逆向函数将其还原为 10 进制 ID如 84729104。路由计算库索引 ID % 16表索引 (ID / 16) % 64。精准定位到某一个库的某一张表耗时小于 5ms。方案二列式/KV 分布式数据库 (NoSQL)如果不愿意维护复杂的 MySQL 分库分表集群可以直接选用天生支持分布式扩展的数据库MongoDB自带 Sharding 机制通过 short_code 作为片键Shard Key自动将 2.2 TB 数据打散到各个节点。HBase / ScyllaDB以 short_code 作为 RowKey读写性能极高非常适合这种纯粹的 KV 场景4. 读写分离架构细化针对“写少读多”的特性采用分层高并发架构A. 写路径优化 (生成短链)号段模式发号器使用 Redis 或美团 Leaf 搭建分布式发号器。短链服务每次批量取走 5 万个 ID 缓存在本地内存中写请求直接在内存自增分配 ID速度达微秒级。异步落库如果对极端情况下的“绝对不丢数据”要求不高写请求生成短链后可以先写入 Redis 并返回给用户同时发一条消息到 Kafka由消费服务异步批量写入 MySQL。这能瞬间把写吞吐量提升数倍。B. 读路径优化 (302 重定向) - 抗住 30,000 QPS面对海量突发流量如营销短信群发后的点击洪峰绝对不能让请求直接打到数据库。多级缓存策略一级缓存 (本地内存)在短链服务实例内部使用 Caffeine 缓存最热的 10 万个短链。二级缓存 (分布式缓存)使用 Redis 集群作为主缓存采用 LRU 淘汰策略。因为点击具有严重的“时间局部性”新生成的短链在刚发出的 48 小时内点击率占 90% 以上过期链接很少有人点Redis 只需要缓存近几天的热数据即可内存开销并不大。防黑客刷接口布隆过滤器110 亿的数据规模如果黑客恶意随机生成未注册的短链码疯狂请求会造成缓存穿透打挂数据库。落地方案在 Redis 前置一个分布式布隆过滤器。110 亿个 64 位整数布隆过滤器所需的内存大小约为110亿×10bit≈13.7GB110亿 \times 10 bit \approx 13.7 GB110亿×10bit≈13.7GB。仅需十几个 GB 的内存就能在缓存之前拦截掉 99% 的非法无效请求。附录在分布式自增 ID 方案中最大的痛点就是容易被猜出规律。如果你的短链码是按照顺序递增的例如 Xy7Z8a、Xy7Z8b、Xy7Z8c竞争对手只需要写一个简单的脚本把最后一个字符按顺序往下累加就能把你系统中所有的长链接全部爬取出来。这不仅暴露了商业机密比如你今天发了多少个营销链接还会带来巨大的安全隐患。为了解决这个问题我们可以采用位移Bit Shuffling或混淆矩阵Alphabet Shuffle。它们的共同特点是不需要加密算法直接在 ID 转换过程中通过“障眼法”彻底打乱顺序。混淆矩阵这是最简单、最常用且效果极佳的方法。1. 传统做法未混淆通常我们的 62 进制字符集是按标准顺序排列的0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ当 ID 1 时对应的短链码是 1当 ID 2 时对应的短链码是 2这样生成出来的短链就是000001、000002、000003……极其容易被猜到2. 混淆做法我们不改变数学上的进制转换逻辑只把这 62 个字符的内部顺序彻底打乱洗牌。例如我们自己定义一个随机顺序的字符集这就是混淆矩阵qazwsxedcrfvtgbyhnujmikolp0987654321QAZWSXEDCRFVTGBYHNUJMIKOLP此时我们再用这个乱序的字符集去做 10 进制转 62 进制当 ID 1 时取第 2 个字符结果变成了 a当 ID 2 时取第 3 个字符结果变成了 z当 ID 3 时结果变成了 w效果从人类的视角来看生成的短链码变成了 00000a、00000z、00000w……连续的自增 ID 变成了看似毫无规律的乱码。但对计算机来说它只是查了另一个普通的表格而已性能完全不受影响。