企业官网建设流程全解析

摘要：短链系统几乎是每一家大厂系统设计面试的高频考题。本文从需求澄清、核心短码生成、存储建模、缓存加速、一致性处理、高可用架构、限流防刷、统计链路到面试追问，完整梳理一套可以扛住大流量、低延迟、可扩展的短链系统设计方案，并给出大量可直接复用的数据估算、代码示例和演进思路。

一、为什么短链系统值得反复考？

短链系统看似简单，本质就是一个“长链接换短链接”的映射服务。但把它放到亿级用户、海量并发、低延迟、高可用的生产环境里，问题会迅速放大：如何生成全局唯一的短码？如何保证同一个长链尽量不产生大量重复短链？如何做到跳转耗时在几毫秒甚至更低？如何扛住热点的突发流量？如何防止被刷爆、被滥用？这些点串联起来，恰好覆盖了系统设计面试里最常考察的模块。

字节三面通常不会只满足于“用哈希生成短码就行了”这种回答。面试官更关心的是你在不同规模下如何做取舍：为什么 Base62？为什么用跳转表而不是直接在主表上查？为什么缓存要加布隆过滤器？为什么要分库分表？为什么热点短链需要本地缓存？这套问题链的背后，是在考察你“从业务需求推到架构，再做容量与代价估算”的能力。

二、先做需求澄清：题目没说的边界要自己问出来

很多候选人在面试中一上来就画架构图，结果方向完全跑偏。比如短链是否需要过期？是否需要统计访问量？是否需要允许用户自定义短码？这些都会直接改变存储和写入模型。正式设计前，建议先和面试官确认以下几类需求。

2.1 功能需求

• 生成短链：用户输入一个原始长链，系统返回一个短链。
• 跳转重定向：访问短链时，快速找到原始长链并完成 301 或 302 跳转。
• 查询与校验：需要校验传入长链的合法性，避免把非法地址写入系统。
• 可选能力：自定义短码、过期时间、访问次数上限、短链删除或封禁。

2.2 非功能需求

• 低延迟：跳转是核心链路，通常要求 P99 在几十毫秒内甚至更低。
• 高可用：短链一旦生成，跳转服务应具备极高可用性，不能因为缓存穿透或单点故障影响访问。
• 可扩展：写入量和读取量增长后，系统能通过水平扩展平滑扩容。
• 可观测：能统计访问量、访问来源、设备、地域和异常流量，辅助运营与风控。

2.3 规模假设

为了后续做容量估算，可以先假设一组常见参数：日均生成短链约 1 亿条，读写比约 100:1，也就是日均读取量约 100 亿次。平均每条记录保存约 3 年。这些数字可以根据面试官的要求放大或缩小，但有了假设，才能推导出存储量、QPS 和带宽。

三、核心原理：短链到底在“缩短”什么

短链的本质是一个 KV 映射：短码是 Key，长链接是 Value。访问短链时，客户端发出一个 HTTP 请求，服务端根据路径中的短码查表，拿到原始长链后返回重定向响应，浏览器随后跳转到目标页面。真正被缩短的是“传输和展示长度”，并不是把原始链接压缩进短码本身。

例如长链是：

https://example.com/articles/very-long-path?token=abc123&from=share&campaign_id=9999

对应短链可能是：

https://t.cn/A8xYz9Q

其中A8xYz9Q是短码。系统维护一张映射表，跳转时根据短码查询到原始长链。

3.1 重定向状态码怎么选？

301 表示永久重定向，浏览器可能对这个短链做本地缓存，后续访问不再回源。这对降低服务端压力有帮助，但会导致后续想修改短链指向的目标时，老浏览器仍跳向旧地址，也不利于精确统计点击。

302 表示临时重定向，浏览器一般不会把结果长期缓存，每次访问都会到短链服务查询。这样便于动态修改目标地址，也便于统计每次点击。多数短链产品在“统计优先”的场景下选择 302，在“极致性能优先”的场景下选择 301。面试中明确指出这个权衡，会显得你对细节有控制力。

四、短码生成：从“取哈希”到可扩展的唯一 ID 方案

短码生成是短链系统里最容易踩坑的一环。核心目标有三个：短码尽量短、全局唯一、不引入明显冲突。

4.1 方案一：对长链做哈希再截断

简单做法是取长链的 MD5 或 SHA-1，截取前若干位作为短码。它的好处是同一长链重复生成时，理论上能得到相同短码。但问题十分突出：哈希截断后的冲突率会显著上升，真实长链往往只差几个参数，截断后碰撞概率不低。而且哈希结果通常是十六进制字符串，字符集利用率不高。

import hashlib def naive_short_code(long_url): digest = hashlib.md5(long_url.encode("utf-8")).hexdigest() # 示例：截取前 8 位十六进制字符 return digest[:8] print(naive_short_code("https://example.com/a")) 输出类似：7f138a09

这种方案只适合解释原理，不适合直接用于生产。面试时可以作为“初始直觉方案”提出来，再顺势分析为什么不行。

4.2 方案二：自增 ID + Base62 编码

这是最常见、也最值得推荐的思路。系统维护一个全局唯一的数字 ID，再把这个十进制 ID 转成 62 进制字符串。62 个字符由数字、小写字母和大写字母组成，相比纯数字或十六进制，能在同样位宽下表达更大的空间。

ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" BASE = 62 def encode_base62(num): if num == 0: return ALPHABET[0] chars = [] while num > 0: num, rem = divmod(num, BASE) chars.append(ALPHABET[rem]) return "".join(reversed(chars)) def decode_base62(code): num = 0 for ch in code: num = num * BASE + ALPHABET.index(ch) return num print(encode_base62(125)) # 21 print(encode_base62(19158)) # e9a print(encode_base62(916132832)) # 62进制示例

使用自增 ID 的好处是唯一性由 ID 生成器保证，存储结构简单，短码可以随 ID 自然增长，第一万个、第一亿个链接的短码长度会逐渐变化。例如 6 位 62 进制可以表示约 568 亿个 ID，足以支撑大多数业务场景。

4.3 方案三：基于 Range 的号段发号

自增 ID 如果完全依赖单个数据库自增主键，写入瓶颈会非常明显。更高性能的做法是让每个发号节点先从号段服务批量领取一段连续的 ID 区间，例如一次性领取 1 万到 2 万个 ID，在本地内存中持续发放。这样大部分写入请求不需要每次都访问 ID 生成器。

号段服务可以基于数据库的UPDATE ... SET max_id = max_id + step原子操作，配合事务保证不重发。单次批量领取会引入一定量的 ID 浪费，例如节点宕机后本地未用完的号段会跳过，但这种代价在短链场景下完全可接受。

4.4 方案四：Snowflake 雪花算法

雪花算法可以生成 64 位分布式唯一 ID，由时间戳、机房/机器号和序列号组成。它的优势是高性能、趋势递增、不依赖中心数据库。缺点也很明显：数字 ID 经过 Base62 编码后仍然较长，而且时间戳部分可能暴露生成时间。

public class SnowflakeIdWorker { private final long workerId; private final long datacenterId; private long sequence = 0L; private final long twepoch = 1288834974657L; private final long workerIdBits = 5L; private final long datacenterIdBits = 5L; private final long maxWorkerId = -1L ^ (-1L << workerIdBits); private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); private final long sequenceBits = 12L; private final long workerIdShift = sequenceBits; private final long datacenterIdShift = sequenceBits + workerIdBits; private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; private final long sequenceMask = -1L ^ (-1L << sequenceBits); private long lastTimestamp = -1L; public SnowflakeIdWorker(long workerId, long datacenterId) { if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException("workerId 超出范围"); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException("datacenterId 超出范围"); } this.workerId = workerId; this.datacenterId = datacenterId; } public synchronized long nextId() { long timestamp = timeGen(); if (timestamp < lastTimestamp) { throw new RuntimeException("时钟回拨"); } if (timestamp == lastTimestamp) { sequence = (sequence + 1) & sequenceMask; if (sequence == 0) { timestamp = tilNextMillis(lastTimestamp); } } else { sequence = 0L; } lastTimestamp = timestamp; return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } private long timeGen() { return System.currentTimeMillis(); } }

在实际设计里，自增号段和雪花算法都可以作为发号器，关键是要讲清“为什么这样选”。如果想让短链尽可能短，且方便后续按时间范围做数据归档，可以用独立发号服务；如果更看重无状态、去中心化，可以用雪花算法。

4.5 同一长链重复生码的问题

用户可能对同一个长链多次生成短链。如果每次都用新的自增 ID，会产生多条重复映射，浪费存储，也会让统计分散。解决办法通常是先查后生成：对长链计算一个指纹，在存储层建唯一索引，命中时直接返回已有短码；未命中再走发号流程。

但“先查再写”会带来并发下重复写入的问题。可以在存储层用INSERT IGNORE或唯一索引冲突重试来兜底，避免同一长链在并发下产生多条重复记录。

五、短码长度与容量估算

面试中非常喜欢追问“你的短码用几位，为什么”。短码长度决定了可表达空间、存储索引大小和用户体验。以下是一个常见估算逻辑。

假设使用 62 进制，短码长度为 n，则可以表示 62 的 n 次方个唯一值。不同长度的可表示数量如下：

如果日均生成 1 亿条短链，一年约 365 亿条。用 6 位短码可以支撑约 1.5 年的唯一 ID；用 7 位则可以支撑更长时间。大多数系统会选择 6 到 8 位，并在后续按需增长。

存储量方面，假设每条记录包含短码、长链、创建时间、过期时间等字段，平均按 1 KB 估算。1 亿条记录大约占用 100 GB。3 年累计约 30 亿条记录，单表很难扛住，因此必然需要分库分表。

六、存储设计：关系型数据库与 KV 的取舍

短链系统的访问模式非常特殊：写入相对低频，读取极高频，查询维度主要是“短码到长链”。因此，存储层的设计方向非常明确：用 KV 语义高效承载点查。

6.1 为什么点查更适合 KV？

如果只用关系型数据库，跳转每次都要执行一条SELECT，即使主键索引很快，单库在高 QPS 下仍然会遭遇连接数、磁盘 IO 和锁竞争压力。Redis、Aerospike、HBase 等 KV 存储以短码为 Key，长链为 Value，天然匹配点查场景，读取延迟通常能控制到毫秒级。

6.2 常见存储分层

推荐采用“关系型数据库保底 + KV 加速读”的架构：

• MySQL 等关系库：作为最终一致的数据源，保存明细、账号关系、状态等。
• Redis/本地缓存：作为热数据加速层，承载绝大多数跳转查询。
• 搜索引擎或分析引擎：用于过期短链清理、统计分析和运营查询。

6.3 分库分表策略

对于写入量大的关系库，可以按短码做哈希分片。切分键不要简单用自增 ID，因为自增 ID 是趋势递增的，容易造成尾部热点。更好的做法是对短码本身或短码哈希值取模，让写入均匀分布到多个分片。

如果使用分布式 KV，则可以直接利用集群自身的分区能力。Redis 的 Cluster 模式、Aerospike 的自动分区、HBase 的 Region 分区，都无需应用层手动分片。

6.4 主键设计

如果关系库按短码作为主键，跳转查询可以直接命中主键索引。短码是字符串，适合作为业务主键。也可以保留自增数字 ID 作为内部 ID，再对短码建立唯一索引。两者的本质差异在于索引空间和维护成本，面试中能说明“以短码为主键可以省一次回表”就很加分。

七、缓存设计：多级缓存与热点数据

缓存是短链系统的性能核心。没有缓存的短链服务，在高并发下很快会被数据库拖垮。

7.1 多级缓存结构

• 第一级：应用本地缓存：如 Caffeine、Guava Cache，命中延迟可低至微秒级，但容量有限，且各实例缓存独立。
• 第二级：分布式缓存：如 Redis Cluster，容量大、命中率高，但网络访问需要一次 RTT。
• 第三级：持久层：缓存未命中时回源查询，同时把结果回填至缓存。

7.2 缓存策略

短链的映射关系相对稳定，适合设置较长的缓存过期时间。短码一旦创建，长链大部分情况下不会再变，可以给缓存设置 24 小时到 7 天不等的 TTL，并配合主动失效机制。

对于热点短链，也就是少数链接占了大量访问量，不能完全依赖 Redis 单 Key。可以考虑在应用层识别热点并增加本地缓存，让高频访问命中实例内存，减少对 Redis 和数据库的压力。

7.3 热点识别与本地缓存

热点短链的访问通常具有突发性和集中性，例如某个营销活动短链被大量转发后，流量可能在几分钟内快速上升。想要让本地缓存发挥作用，需要先解决“哪些短码值得放入本地缓存”的问题。常见做法有两类：

• 阈值触发：对每个短码的访问次数做窗口统计，当某短码在短时间内超过阈值时，将其标记为热点并异步推送到各实例本地缓存。
• 预测加载：对刚创建的重要活动链接、大 V 发布的链接，或带有活动标记的链接，提前写入本地缓存。

判断热点时需要尽量少地引入额外延迟。可以在网关层或短链服务内使用近似统计结构，用较小内存获得高频元素的近似次数：

// 示意：使用 Caffeine 统计访问次数，判断短码是否成为热点 import com.github.benmanes.caffeine.cache.Cache; import com.github.benmanes.caffeine.cache.Caffeine; public class HotKeyDetector { private final Cache<String, Long> counter = Caffeine.newBuilder() .maximumSize(100_000) .build(); public boolean recordAndCheck(String shortCode, long threshold) { // 简化统计：生产环境可结合 Redis 计数器或滑动窗口 long newCount = counter.asMap().merge(shortCode, 1L, Long::sum); return newCount &gt; threshold; } }

热点列表确定后，可以通过广播或配置中心推送到各个服务节点。节点在本地缓存中单独维护一份热点映射，并设置更短甚至不过期的 TTL，同时由热点管理任务负责随流量下降逐渐下线已经冷却的热点。

7.4 缓存穿透、击穿与雪崩

缓存设计必须同时处理三类经典问题：

• 缓存穿透：请求的短码在数据库中根本不存在，导致每次查询都穿透到数据库。可在最外层部署布隆过滤器，用较小的内存代价判断某个短码是否可能存在；如果布隆过滤器判定不存在，则直接返回 404，不查缓存也不查库。
• 缓存击穿：某个热点短码的缓存刚好过期，大量请求同时打到数据库。可以为热点 Key 设置互斥锁，只允许一个线程回源加载，其余线程短暂等待；也可以使用“逻辑过期”机制，让热点 Key 在物理上不过期，由后端任务检查目标值是否已更新。
• 缓存雪崩：大量缓存集中在同一时间过期，压力同时倒向数据库。解决方式是为 TTL 增加随机值，避免集中失效，同时对不同层级的缓存做容量和过期策略隔离。

八、一致性处理：缓存和数据库如何配合

短链系统里一致性问题的核心是：当长链被修改、删除或封禁时，缓存里的旧映射需要尽快失效，不能让用户继续跳到错误地址。

8.1 短链场景的一致性特点

与电商库存、账户余额这类强一致场景不同，短链映射读多写少、更新频率极低。绝大多数短链创建后不会变化，因此可以接受短时间的最终一致：即使存在毫秒到秒级的缓存旧值，通常也不会造成严重业务问题。对于封禁、删除这类安全相关操作，则需要提供更快的主动失效能力。

8.2 推荐写路径

生成短链时，先写数据库，再写缓存或直接让跳转请求回源加载。更新或封禁短链时，可以采用“先更新数据库，再删除缓存”的顺序：

1. 数据库完成更新。
2. 删除对应的 Redis Key，必要时同时删除本地缓存。
3. 后续跳转请求未命中缓存后回源，读取到最新映射并重新回填。

如果担心极端情况下读到旧缓存，可以通过版本号或逻辑过期时间给缓存值增加一个较短的兜底 TTL，保证旧值不会长期存在。

8.3 删除与封禁的即时生效

对于删除短链、封禁短链等强管控操作，不能只依赖 TTL 过期。可以在管理后台操作时同步发布失效消息到消息队列，各服务节点消费后清理本地缓存，再由缓存服务删除 Redis Key。这样既保证了跨实例一致性，又避免逐个节点的手工清理。

8.4 为什么短链系统一般不选强一致方案

如果每次跳转都要经过分布式锁、版本校验或分布式事务，延迟和复杂度会显著上升，而收益却很低。短链的核心目标是低延迟跳转，因此更适合使用缓存加速加最终一致性的方式，把强一致能力只保留在极少数的管控操作上。

九、高可用架构：让服务始终可跳转

高可用要从服务层、数据层和机房层分别考虑。短链一旦对外发布，跳转服务的中断会直接影响用户体验，甚至影响投放效果。

9.1 服务层无状态化

短链服务应设计成无状态节点，短码到长链的映射都放在缓存或数据库中，节点本身不保存唯一数据。这样任何实例都可以独立处理请求，扩容时只需要增加节点并接入负载均衡。

长链接入层使用 Nginx、OpenResty 或云负载均衡，结合健康检查和自动摘除机制，保证单个节点故障不会把流量打到异常实例上。

9.2 数据层高可用

关系库可以使用主从复制加读写分离，写入走主库，少量管理查询走从库。Redis 使用哨兵模式或 Cluster 模式提供自动故障转移：哨兵适合主从结构，Cluster 适合数据分片和大容量场景。

缓存节点绝不能让所有流量只依赖一个主实例。通过 Redis Cluster 的多主多从架构，某个分片故障时可以由从节点接管，最大限度减少热点单分片故障的影响。

9.3 多机房与异地容灾

对于更高可用等级的要求，可以采用同城双机房或两地三中心部署。短链服务本身就是读多写少的系统，跨机房异步同步核心数据的压力不大。关键是跳转时要优先访问本机房的缓存和数据库，避免跨机房 RTT。

域名解析层可以配合全局负载均衡，把用户请求调度到最近、最健康的机房；当某个机房出现故障时快速切流。

9.4 降级与兜底

当缓存和数据库都不可用时，跳转服务不可能凭空知道短码对应的长链。此时更现实的兜底策略是：

• 对已确认的热点短链，把映射预置到各节点本地文件，作为极端情况下的只读降级数据。
• 对无法命中的短码，返回友好的错误页，而不是让用户看到超时或 5xx。
• 生成接口做限流降级，保证核心跳转能力不被大量写入请求拖垮。

十、限流、防刷与安全设计

短链服务天然暴露在公网，必须防止被脚本批量生成、被用作垃圾流量中转，或被用于传播恶意链接。

10.1 生成接口限流

生成短链是成本较低的接口，容易被脚本批量调用。可按用户、IP、设备指纹等维度做令牌桶或漏桶限流，例如单 IP 每分钟最多生成 10 条。对于登录用户可以放宽额度，同时把异常高频调用交给风控系统判定。

10.2 跳转接口防刷

跳转请求的量级远高于生成请求，防刷重点在于识别“异常访问模式”而不是简单限流。可以在网关层统计单位时间内同一 IP、同一设备或同一短码的访问次数，对明显异常流量做验证码、拦截或降级。

10.3 恶意链接校验

生成短链前必须校验目标域名，使用黑名单拦截钓鱼、诈骗、色情等非法地址；同时可以接入第三方安全服务对长链做实时检测。对于已发布的短链，还需要支持人工或自动巡检，发现违规后立即封禁。

10.4 风控与审计

把生成和跳转的关键日志接入风控平台，记录 IP、设备指纹、来源和操作时间。风控系统可以通过规则引擎识别批量注册、批量生成、异常跳转等行为，并对高风险账号或短码自动处置。

十一、访问统计与可观测链路

短链的一个重要产品价值是点击统计：运营人员需要知道一个链接被点击了多少次、来自哪些渠道、发生在什么时间和地区。

11.1 统计维度

常见的统计维度包括：点击量 PV、独立访客 UV、来源渠道、设备类型、操作系统、浏览器、地域、访问时间和转化率。对于营销活动，还需要把统计结果聚合到活动维度。

11.2 异步埋点与消息队列

跳转主链路不能因为统计写入而变慢。推荐在跳转成功时只做轻量埋点，把日志异步发送到 Kafka 等消息队列，再由下游消费者完成清洗、聚合和入库。这样跳转延迟基本不受统计成本影响。

跳转请求 -> 短链服务 -> 返回重定向 | +-> 异步埋点 -> Kafka -> 聚合服务 -> 分析存储

11.3 分析存储选型

统计数据适合存放到 ClickHouse、Doris、StarRocks 等 OLAP 引擎中，这类引擎对海量数据的聚合查询支持更好。明细日志可以短期保留在 Kafka 或对象存储，聚合结果再写入分析引擎供报表查询。

11.4 监控告警

系统监控应覆盖请求量、P99 延迟、缓存命中率、数据库 QPS、错误率和队列积压等指标。告警规则要区分错误和延迟抖动，例如缓存命中率突然下降可能意味着热点失效或配置异常，需要及时排查。

十二、完整架构与两条核心请求链路

把以上模块串起来，可以得到一套完整的短链系统架构：接入层负责路由和限流，短链服务负责生成和跳转，发号器负责唯一 ID，关系库负责持久化，Redis 和本地缓存负责加速读，消息队列和 OLAP 负责统计分析。

flowchart LR A[用户/客户端] --> B[负载均衡/网关] B --> C[短链服务集群] C --> D[发号器] C --> E[MySQL] C --> F[Redis] C --> G[Kafka] G --> H[聚合服务] H --> I[OLAP] C --> J[风控/安全服务]

12.1 生成短链链路

1. 用户提交长链，网关完成限流和鉴权。
2. 短链服务先校验长链合法性和域名安全。
3. 对长链计算指纹，查询是否已有短码，若有则直接返回。
4. 若没有，从发号器领取唯一 ID，用 Base62 编码得到短码。
5. 写入数据库，写入缓存，并把短码返回给用户。

12.2 跳转短链链路

1. 用户访问短链，网关完成基础防护。
2. 服务从本地缓存查询，未命中再查 Redis，仍未命中则查数据库。
3. 查到长链后回填缓存，异步发送统计埋点。
4. 根据配置返回 301 或 302 跳转。

十三、面试追问与回答要点

追问一：为什么短码用 Base62，而不用 Base64？

Base64 带有 +、/、= 等字符，放在 URL 路径中需要额外转义，容易出错。Base62 只使用数字和大小写字母，天然适合 URL 场景，也便于人工复制和输入。

追问二：自增 ID 会不会泄露业务量？

会。纯自增 ID 编码后，短码长度随时间变化，竞争者可以大致推断生成量。如果介意，可以在发号时做位扰乱或随机化，也可以用雪花算法这类带时间戳的方案，同时接受短码略长的代价。

追问三：怎么防止同一个长链生成多个短码？

为长链指纹建立唯一索引，先按指纹查询，命中则返回已有短码；未命中再发号写入。并发场景用唯一索引冲突重试兜底，避免重复映射。

追问四：本地缓存怎么保证多实例一致性？

普通映射依靠较短的 TTL 和 Redis 作为共享层来收敛不一致；封禁、删除等管控操作通过消息队列广播失效，让各实例主动清理本地缓存。

追问五：缓存击穿和穿透怎么区分？

穿透是查的数据根本不存在，击穿是热点数据刚好过期。处理上，穿透用布隆过滤器或空值缓存，击穿用互斥锁或逻辑过期。

追问六：统计为什么不能同步写数据库？

统计写入量大，同步写入会让跳转主链路延迟明显上升。异步埋点到 Kafka 后由下游聚合，能解耦主链路和分析链路，也便于削峰。

十四、总结

高性能短链系统的设计并不复杂，难的是把每个环节的取舍讲清楚。核心可以归纳为：用 Base62 编码配合唯一 ID 生成器生成短码，用关系库做主存储、用 Redis 和本地缓存加速读，用布隆过滤器保护缓存，用异步日志支撑统计，再通过限流、风控、多级缓存和高可用部署保证稳定。

回答这类问题时，建议始终从规模估算出发，先把需求边界和数据量讲明白，再依次展开生成、存储、缓存、一致性、高可用和安全设计，最后回到成本与演进。这样的结构既清晰，也能给面试官留下“能落地、能权衡”的印象。