企业官网建设流程全解析

核心业务流程

短链系统的核心任务是将一个长的 URL 转换为一个短的 URL，并在用户访问短链时，快速、准确地重定向到原始链接

短链系统的核心只有两个动作：生成短链和重定向访问

生成短链（长变短）

长链接→\rightarrow→系统校验并转换为短链接→\rightarrow→存入数据库→\rightarrow→返回给用户

重定向访问（短变长）

用户点击短链→\rightarrow→服务端解析短链→\rightarrow→查表找到长链→\rightarrow→通过 301/302 状态码 重定向到目标网站

选择301重定向还是302重定向

301 (永久重定向)：浏览器会缓存该关系，下次访问直接走浏览器缓存，减轻短链服务器压力。缺点是无法精确统计每一次的点击数据（如 PV/UV）

302 (临时重定向)：每次访问都会经过短链服务器，方便收集分析数据（地理位置、点击量等）。缺点是服务器压力大

为了减轻服务器压力选择301，方便数据分析选择302

表可以定义为如下

核心算法：如何将长链变短？

方案一：哈希算法（如 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）或 NoSQL（Redis + 持久化 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 亿条数据

单条数据大小估计：

加上索引开销，单条数据约 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 变成了看似毫无规律的乱码。但对计算机来说，它只是查了另一个普通的表格而已，性能完全不受影响。