企业官网建设流程全解析

短链项目的复习进行到第二天了。Day01我把接口定义和数据模型重新过了一遍，今天集中精力把最核心的生成-存储-跳转链路重新走通了。说实话，这种"个人项目复习"最怕的就是当时写的时候能跑，回头一看细节全是问号。这篇主要是把我在复习短链过程中重新梳理的关键决策、代码逻辑和一些踩过的坑整理出来，给同样在做短链系统、或者想复习自己老项目的朋友一个参考。

1. 复习复盘从链路图开始：一条短链从创建到跳转经历了什么

1.1 先把整条路径放在桌面上

短链这个东西，原理看起来简单得吓人：把长URL压缩成短URL，用户点短链再跳回去。但真正自己写一遍就会知道，水比想象中深。我复习时第一件事不是看某段代码，而是把整条链路从两个方向各走了一遍。

创建方向：客户端提交长URL → 服务端校验参数和域名合法性 → 生成短码 → 写入短链表 → 预热缓存 → 返回完整短链地址。

访问方向：用户点击短链 → DNS解析到服务 → 网关/负载均衡 → 短链服务解析短码 → 查缓存 → 缓存未命中则查数据库 → 判断是否过期 → 返回302跳转到目标URL → 异步记录点击流水。

这两条链路一拆开，就能清楚看到短链系统其实就是两个核心问题：生成端要解决"短码怎么来、怎么不冲突、怎么不浪费"，读取端要解决"怎么最快把短码映射成长URL、怎么挡掉恶意请求、怎么处理过期数据"。

1.2 为什么复习要先看链路而不是看代码

我个人的习惯是，复习老项目时先画链路图而不是直接翻代码。因为代码是"当时的结果"，链路图才是"当时的思考过程"。很多设计决策，比如为什么用这个字段、为什么在这里加缓存、为什么跳转用302，单独看代码是看不出原因的，但放在链路里，每个节点的存在都有它的理由。

画链路的同时，我会在每个节点旁边标注几个问题：这个节点有没有可能成为瓶颈？如果流量翻10倍，哪个节点先挂？如果请求不合法，能不能在这一层就拦住？

这套复习方法非常实用。短链这种读多写少的系统，瓶颈几乎一定出现在读取方向，要么是缓存扛不住，要么是数据库回源太频繁，要么是恶意扫描穿透了所有保护直达DB。后面几节的内容，其实就是围绕这条链路逐段展开的。

1.3 Day02要重点确认的三个节点

这次我重点确认了三个节点：短码生成、缓存回源、跳转响应。

短码生成决定的是短链系统的地基。短码长度、字符集、生成方式、碰撞处理，每一项都直接影响后面的缓存设计和DB索引设计。

缓存回源决定的是性能上限。缓存命中率高了，DB压力自然就小；但缓存怎么防击穿、防穿透、防雪崩，都是要在链路里真刀真枪解决的问题。

跳转响应决定的是用户体验和统计准确性。301和302的选择、统计的埋点、安全校验放在哪一层，这些细节都要在跳转那一下里安排好。

这三个节点确认完，Day02的主线就很清晰了。

2. 短码生成的两条路线：发号器与随机短码的工程取舍

2.1 发号器方案：自增ID转62进制

发号器是短链系统里最经典的方案。思路很简单：维护一个自增的数字ID，然后把数字转换成固定长度的62进制字符串（0-9、a-z、A-Z），这个字符串就是短码。

数字转62进制的代码很简单，但有几个值得注意的细节。字符集顺序会影响短码的字典序和可读性，我建议数字、小写、大写的顺序固定下来，别东拼西凑：

ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" def to_base62(num: int) -> str: if num == 0: return ALPHABET[0] chars = [] while num > 0: num, rem = divmod(num, 62) chars.append(ALPHABET[rem]) return "".join(reversed(chars))

注意这里有几个测试用例值得自检：ID为1时返回1，ID为61时返回Z（因为下标61是最后一个字符），ID为62时返回10，ID为1234时返回jU。这些边界值如果不在写代码时自测一遍，上线后很容易出诡异问题。

发号器本身怎么实现，有几种选择：

单库自增ID是最简单的方式，直接依赖MySQL的auto_increment，生成短码时INSERT拿到自增ID再转62进制。问题在于：自增ID本身是连续的，攻击者可以通过短码反推业务量，而且单库自增在写入量上来后会成为瓶颈。

Redis批量取号是我这次复习时重新审视的一个方案。用Redis的INCRBY一次性取一段ID区间，然后在应用内存里慢慢分配，减少对Redis的请求次数：

import redis r = redis.Redis(host="redis", port=6379, decode_responses=True) BATCH_SIZE = 100 def get_id_batch(): # 每调用一次，Redis把计数器增加100，返回新的最大值 new_max = r.incrby("short_url:seq", BATCH_SIZE) # 应用本地获得 [new_max - BATCH_SIZE + 1, new_max] 这段ID return range(new_max - BATCH_SIZE + 1, new_max + 1)

这种方案的好处是Redis操作频率降低了100倍，应用启动时取一批号放内存，用完再取。坏处是如果应用拿到一批号之后崩溃了，这批号就永久浪费了，短码总量和DB行数会对不上。

雪花算法是另一个常见选择，它不依赖Redis，也不依赖数据库自增，而是通过时间戳+机器ID+序列号生成一个全局唯一的int64。但雪花ID转成62进制之后，短码会比较长，因为雪花ID本身很大，62进制转换后通常在10-11位，对短链来说有点偏长。

2.2 随机短码方案：空间换可预测性

随机短码的思路是完全不依赖发号器，直接从62个字符里随机抽6到7位作为短码。好处很明显：不可枚举，别人猜不到相邻短码，想批量抓取短链会困难很多。

但随机方案绕不开一个数学问题：碰撞概率。以6位短码为例，总空间是62的6次方，约568亿个组合。假设系统里已经有m条短码记录，插入一条新短码时发生冲突的概率就是m除以总空间。

算一下：当m为100万时，冲突概率约百万分之1.76，看起来很低；但当m达到1亿时，冲突概率就变成了约万分之1.76。如果用7位短码，总空间提升到约3.5万亿，1亿条记录时冲突概率降到百万分之2.8。

所以随机短码方案里，"生成后查一下是否已存在"这一步是必须的，不能省。实际工程中就是用数据库的唯一索引兜底，插入时如果报唯一键冲突，重新生成短码再试一次，一般重试两三次就能成功。

2.3 布隆过滤器优化随机短码的查重

随机短码方案如果每次都因为潜在冲突去查数据库，在高并发创建场景下仍然会形成不必要的DB压力。我在复习时把布隆过滤器加在了短码生成之前：先生成候选短码，用布隆过滤器判断是否存在，如果过滤器说"不存在"，就直接尝试插入；如果过滤器说"可能存在"，再走唯一索引冲突重试。

布隆过滤器的原理不复杂，它用多个哈希函数把元素映射到一个位数组上，查询时如果任何一个位为0，说明元素一定不存在；如果所有位都是1，说明元素可能存在，但不等同于一定存在。这种特性非常适合"低概率冲突但能挡掉绝大多数重复查询"的场景。

用Redis的bitmap和两个哈希函数就可以实现一个简版：

import hashlib BIT_SIZE = 200_000_000 # 20亿bit，约250MB？其实这里用2亿bit更合理 BIT_SIZE = 200_000_000 def _hash_double(short_code: str): h1 = int(hashlib.md5(short_code.encode()).hexdigest()[:8], 16) h2 = int(hashlib.sha256(short_code.encode()).hexdigest()[:8], 16) return (h1 % BIT_SIZE, (h1 + h2) % BIT_SIZE) def bf_add(r, short_code: str): p1, p2 = _hash_double(short_code) r.setbit("short_url:bloom", p1, 1) r.setbit("short_url:bloom", p2, 1) def bf_exists(r, short_code: str) -> bool: p1, p2 = _hash_double(short_code) return r.getbit("short_url:bloom", p1) and r.getbit("short_url:bloom", p2)

生产环境如果不想自己维护，可以直接用RedisBloom模块，BF.RESERVE、BF.ADD、BF.EXISTS一条命令就搞定。只是要注意，布隆过滤器的误判率会随着已插入元素数量增加而升高，所以位数组大小最好按预估最大数据量的10倍以上来申请，或者定期重建。

2.4 两种方案怎么选

我做了个对比表，方便决策时一眼看清楚：

我的结论是：公开的短链服务优先用随机短码方案，配合布隆过滤器和唯一索引；如果是公司内部短链，用户可信、量也不大，用发号器方案简单省事就够了。我之前那个项目一开始用的发号器，后来为了防枚举切了一部分流量到随机短码，两种模式并存，通过短码校验规则区分来源。

3. 读路径是生命线：表结构、索引与缓存该怎么配合

3.1 短链表结构设计的最终选择

短链系统的表结构，网上很多教程会建议直接用短码作为主键，因为查询时可以避免一次回表。我第一版也是这么干的，但复习时认真想了想，最终还是决定改成自增主键+短码唯一索引的结构。

原因有三点。第一，短码本身是随机字符串（即使是发号器生成的62进制，字典序和自增ID也没关系），如果直接作为主键，新插入的行在主键B+树上的位置是随机的，数据量上去后会造成大量页分裂和写放大；而自增主键是顺序插入，性能稳定得多。第二，短链通常还有过期时间、状态、用户ID等字段，后期做批量软删除、统计都要按这些字段操作，单独的自增主键更方便。第三，短码那一次回表可以用覆盖索引解决，不需要牺牲主键设计。

表结构大概是这样的：

CREATE TABLE short_url ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, short_code VARCHAR(16) NOT NULL COMMENT '短码', long_url VARCHAR(2048) NOT NULL COMMENT '目标长链接', status TINYINT NOT NULL DEFAULT 1 COMMENT '1-生效 0-失效', user_id BIGINT DEFAULT NULL COMMENT '创建者', expires_at DATETIME DEFAULT NULL COMMENT '过期时间，NULL表示永久', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_short_code (short_code), KEY idx_status_expires (status, expires_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3.2 索引设计的两个关键决策

第一个关键是短码唯一索引。短码列的索引必须加UNIQUE，这不仅是性能需求，更是随机短码方案里防止并发创建同码的兜底。没有唯一索引，两个请求同时生成同一个随机短码，会出现两条记录，读路径就只能随机返回其中一条，属于严重事故。

第二个关键是过期清理的索引。idx_status_expires (status, expires_at)这个联合索引就是给第5节的定时清理任务用的。status在前，expires_at在后，可以快速定位"状态生效但已经过期"的行。要注意的是，很多短码是永远不过期的，expires_at为NULL，这类数据不会被索引有效利用，但对规模不算太大的系统问题不大；如果永久短码占绝对多数，可以考虑把永久和临时的短码分成两套表，或者给expires_at加一个默认的远期值比如2038-01-01，保证所有行都有值。

读路径的查询语句也要写对，不要无脑SELECT *：

SELECT long_url, expires_at, status FROM short_url WHERE short_code = %s AND status = 1;

在unique索引上，这条查询走索引覆盖时其实还是需要回表一次拿long_url，所以如果并发量极高，可以建一个(short_code, long_url, expires_at, status)的复合索引来彻底避免回表。但多一个索引多一份写入开销，量级没到百万QPS就不用太纠结。

3.3 缓存层级与Key设计

短链的读路径是典型的"读多写少"，缓存是命脉。完整的缓存设计至少分两层：

本地缓存处理热数据，比如Caffeine，设置几十万的容量、几秒钟的过期时间。这一层用来承接最热的短链流量，避免把压力全部打到Redis。

Redis作为分布式二级缓存，存全量热点数据。Key设计我采用short:code:{shortCode}这种格式，Value直接存long_url。为什么不在Value里再放expires_at和status？因为解析跳转是高频操作，序列化和反序列化的开销越小越好。过期和状态判断放在查询时单独处理，后面会说到。

缓存过期时间不是随便设的。如果短码本身有物理过期时间，比如7天后失效，那么缓存时间应该取min(7天, 业务容忍的缓存时间)。我之前踩过一个坑：短码配置了1小时过期，缓存却设了7天，结果短码已经失效了，用户访问时缓存照样返回302，跳到了本来不该访问的URL。这种问题很隐蔽，写路径上的缓存预热、读路径上的缓存TTL，都要跟短码的过期时间联动。

3.4 缓存读路径的完整逻辑

一个健壮的读路径，不只是"先查缓存，没命中再查库"这么简单。完整的逻辑至少要处理三种异常情况：缓存穿透（查一个根本不存在的短码）、缓存击穿（一个热key恰好失效）、缓存雪崩（大量key同时过期）。

我用非严格伪代码把完整逻辑捋了一遍：

def resolve_short_url(short_code: str): # 1. 参数白名单校验，挡掉不合法字符 if not re.fullmatch(r"[0-9a-zA-Z]{6,8}", short_code): return None # 2. 布隆过滤器快速判断短码是否可能存在，不存就直接返回404 if not bloom_exists(short_code): return None # 3. 查Redis缓存 url = redis.get(f"short:code:{short_code}") if url: return url # 4. 加分布式锁，防止大量请求同时回源DB with redis_lock(f"lock:short:{short_code}"): # 4.1 二次检查缓存（double-check） url = redis.get(f"short:code:{short_code}") if url: return url # 4.2 查DB row = db.query_one(...) if not row or row["status"] != 1: # 4.3 不存在的记录也要短暂缓存，防止恶意穿透 redis.setex(f"short:code:{short_code}", 10, "__NOT_FOUND__") return None if row["expires_at"] and row["expires_at"] < now(): return None # 4.4 只有有效的短码才写入Redis cache_ttl = min(row["expires_at"] - now(), 7 days) if expires else 7 days redis.setex(f"short:code:{short_code}", int(cache_ttl), row["long_url"]) return row["long_url"]

这段逻辑里的几个细节都是踩坑踩出来的。空值也要缓存10秒，这个设计非常关键。如果某个短码不存在，又没法通过布隆过滤器100%挡住（布隆过滤器有误判），恶意用户就可以不断请求随机短码，每次都穿透到DB。加10秒空值缓存之后，同一批随机短码短时间内只会打DB一次。

分布式锁的做法是：先用SET lock:xxx NX PX 3000加锁，拿到锁的线程做DB回源和缓存写入，拿不到锁的线程sleep几十毫秒后重新读缓存。这样能避免缓存刚失效时几百个请求同时打到数据库。当然，如果能保证单机部署，用进程内的互斥锁更简单，但都做短链了，一般还是按分布式去设想。

3.5 缓存写路径：创建短码时就直接预热

既然读路径已经依赖缓存了，创建短码时就应该顺手把缓存写好，而不是等第一次访问时再回源。这样用户体验更好，也能减少不必要的DB查询。

创建接口在写完DB后，执行一次SETEX short:code:{code} {ttl} {long_url}，把缓存预热。注意这里TTL同样要跟expires_at联动。更重要的是，如果创建后短码被管理员手动封禁（status改为0），必须显式删除缓存，否则用户在缓存过期前还能访问到被封禁的链接。我在复习时就发现自己的老代码里漏了这个主动删缓存的动作，后来补上了。

4. 跳转那一下的细节：301/302、统计与安全卡点

4.1 301和302不只是状态码的区别

短链服务的核心出口就是一个HTTP重定向。不少初学者会随手写302，或者随手写301，但这两者的区别对短链系统来说是根本性的。

301是永久重定向，浏览器会把这个跳转关系缓存下来。同一个短码第二次访问时，浏览器直接跳到目标URL，根本不访问短链服务。302是临时重定向，浏览器每次都会先访问短链服务，拿到新的Location之后再去目标页。

两张方案的对比如下：

短链系统选302是行业共识。原因很简单：短链的价值不只是缩短URL，而是可控、可统计、可修改。如果用了301，用户第一次点击后浏览器就记住了跳转地址，之后你改了长URL用户也不一定刷新得过来，点击统计更是直接失真。所以只要不是纯静态的永久推广位，一律用302。

当然，302也有代价，就是每次访问都要打到短链服务。解决的办法就是第3节说的缓存层，只要缓存命中率高，302的开销完全可控。

4.2 点击统计不能阻塞跳转

既然选了302，就绕不开统计。点击次数、用户UA、来源IP、跳转时间，这些都是短链的黄金数据。但统计不应该放在跳转链路上阻塞响应。

推荐的方案是异步化。在解析到long_url之后、返回302之前，把点击事件扔进消息队列或Redis stream，后端再异步消费写入统计表。如果不想引入重型中间件，最简单的做法是Redis里INCR一个计数器，定时批量把计数落库。统计链路哪怕挂了，也不影响正常跳转，这才是正确的服务降级方式。

我在老项目里还把"是否记录统计"做成了短码级别的开关。有些内部使用的短码不需要统计，省掉写Redis的开销。

4.3 短链安全卡点：这里最容易被忽略

短链的本质是一个开放重定向接口，天然容易成为钓鱼和恶意跳转的工具。复习时我把安全卡点重新梳理了一遍，主要在四个位置：

第一，入参校验。短码必须走白名单正则[0-9a-zA-Z]{6,8}，这一步能挡掉大量注入类请求。SQL查询一律参数化，不能拼字符串。

第二，长URL合法性校验。创建短链时，对目标URL做域名级校验，至少要检查协议是否为http/https，不能允许javascript:这类伪协议。公网服务最好维护一个恶意域名黑名单或调用安全眼查接口，拿不准的URL在跳转前先展示一个安全提示页。

第三，频率限制。这个主要是防枚举扫描。发号器生成的短码天然连续可猜，攻击者只要拿到一个短码，就能遍历前后几千个短码，把整个系统的短链数据抓走。随机短码方案能缓解这个问题，但依然需要按IP限制创建频率和解析频率。对解析接口来说，正常用户不可能在一分钟内请求上千个不同的短码，所以这个限流可以设得严格一些。

第四，跳转目标的安全兜底。即使创建时校验过了，目标URL的页面内容也可能在后续变得不安全。比较稳妥的做法是可以配置"跳转前安全检测"，命中风险规则就返回拦截页。完全不校验的裸跳转，风险太高，不建议公网开放。

这些安全卡点不需要每一个都做全套，但至少要清楚自己承担了哪些风险。内部工具可以砍掉安全页，公网服务则建议全部落实。

5. 过期短码的清理与归档：懒删除和定时任务怎么搭

5.1 两条腿走路：查询懒删除+定时任务

短链系统里必然存在大量过期短码。释放短码空间、清理脏数据、避免用户访问到已失效的链接，这些都要求有一个完善的过期处理机制。我复习后确定了两条腿走路的方案：查询时懒删除负责实时判断，定时任务负责批量清理。

懒删除的逻辑其实在第3节的伪代码里已经出现了：读路径查到短码后，如果发现expires_at已经早于当前时间，就直接返回410 Gone或者404，并顺手把缓存删掉。这种做法的好处是不需要额外的扫描任务，坏处是它只处理"有人访问"的过期短码，没人访问的过期行会一直躺在表里。

所以需要定时任务来兜底。每隔一段时间扫描并清理已经过期但还没被物理删除的行。

5.2 定时清理任务的操作细节

定时任务最容易犯的错就是一条DELETE FROM short_url WHERE expires_at < NOW()把全表锁住。数据量稍大，业务就直接被拖垮。正确写法是分批删除：

-- 每次只取1000条过期记录的ID SELECT id FROM short_url WHERE status = 1 AND expires_at < NOW() LIMIT 1000;

拿到这1000个id之后，逐条删除缓存并物理删除DB记录，或者做软删除。删除时用DELETE ... WHERE id IN (...)，主键删除不会扫描全表。

批量操作时注意任务里还要做两件事。一是删除Redis缓存，否则缓存里会残留已经删除的短码，造成"缓存里有、DB里没有"的不一致。二是更新布隆过滤器，因为布隆过滤器不支持删除单个元素，如果使用的是自实现版本，删掉一批短码后过滤器里的位还是1，会导致后续对已删除短码的查询误判为可能存在，最多只是多查一次DB，影响不大。如果确实要精确，BloomFilter的定期重建也是一种方案，比如每天低峰期重建一次。

过期短码到底物理删除还是软删除？我最终的结论是：保留一段时间的软删除状态，用于审计和防误操作，确认真不需保留了再物理删除。可以通过给status字段打标记来实现，查询时一律过滤status=1。

5.3 统计数据和短码数据的分手

这里有个容易忽略的点：过期短码的统计数据，不能被短码的物理删除牵连。

短码本体删了，但点击统计表里还有大量按时间聚合的记录。这些数据对分析用户行为、渠道效果都有价值，不能直接丢。所以统计表的主键是独立的short_code + hour/days，不依赖短链表的外键约束，物理删除短码时不需要同步删除统计记录，查询统计时即使短码已不存在，历史数字依然能查出来。

实际的实现里我会把统计放在ClickHouse或者MongoDB这种适合分析的存储里，MySQL只做主库。对于个人项目来说，一张独立的short_url_stats表就够了，定时从Redis计数落库。

5.4 续期逻辑要跟清理任务配合

用户如果发起续期，把过期时间往后推，这里的处理会比第一次设置稍微复杂一点。

续期接口要做三件事：更新DB里的expires_at、删掉旧缓存、重新写入带新TTL的缓存。注意顺序不能反。如果先写缓存后更新DB，中间这几十毫秒里如果有请求进来，缓存TTL还是旧值，可能很快又过期。我自己习惯的顺序是：先改DB，再删缓存，最后预热新缓存。这样即使删缓存和预热之间存在空窗期，顶多trigger一次DB回源，数据不会错。

6. 复习中发现的三个值得改造的角落

6.1 公开服务必须重视短码枚举问题

这次复习让我最不舒服的一个问题就是：如果还用发号器生成短码，别人拿到一个短码后就可以枚举相邻ID的短码，相当于把整个短链系统的目标URL批量带走了。就算加了限流，也只是降低速度，没有根治。

我最后做的改造是：对外公开的短链全部切到随机短码方案，并且通过布隆过滤器+DB唯一索引双保险。发号器只保留给内部批量导入工具用，因为内部工具的用户本来就可信。

6.2 批量取号要考虑"空洞"问题

Redis批量取号那个方案，应用拿一批ID后如果还没用就崩溃，会浪费一整个BATCH的ID，导致发号器水位线和DB实际行数对不上。这个偏差在没有参考意义的地方确实无所谓，但在做渠道统计时就很恶心：你无法判断一个短码从来没有被创建，还是创建了但被浪费了。

要解决，要么把"批次分配"这个动作做成可恢复的，比如把当前批次号也存进DB，恢复时接着用；要么干脆接受浪费，在监控里记录浪费率 = 发号水位 - 有效短码数，超过阈值报警。我选择后者，因为纠正浪费的复杂度比浪费本身还高。

6.3 不存在短码的空值缓存必须加上

读路径里最容易漏的就是空值缓存。很多人只考虑了"热key失效后怎么防止击穿"，却忽略了一个更常见的场景：攻击者批量请求随机短码，这些短码大概率不存在，如果每次都不命中缓存直接查DB，数据库会被穿透连击打挂。

我的做法是：DB回源之后如果没查到，也往Redis写一个10秒的__NOT_FOUND__空值。这样同一个不存在的短码在10秒内只会穿透一次。配合布隆过滤器，能挡掉99%以上的无意义DB查询。

复习Day02做到这里，我最大的体会是：短链系统真正难的从来不是算法，而是权衡。发号器还是随机短码、自增主键还是短码主键、301还是302、懒删除还是定时清理，每个选择都有代价，只不过有些代价要等流量上来才看得见。复习的意义，大概就是把当时没想明白的代价重新想一遍。