短链接系统设计

高读低写的典型系统设计题

短链接系统是系统设计面试的经典题目：将长 URL 映射到 6-8 位短码（如 bit.ly/abc123），要求 QPS 达到 10 万读 / 1 千写，数据量百亿级，延迟 < 10ms。涵盖哈希冲突处理、缓存分层、数据库分片、自定义短码等核心设计决策。

短链接哈希冲突Base62缓存数据库分片读多写少雪花 ID

STEP_1

容量估算不需要精确，误差 10 倍以内都可以。关键是推导出正确的量级：读 QPS 十万级 → 需要缓存；存储 TB 级 → 需要分片；短码空间百亿级 → 6-7 位 Base62 足够。这些结论直接影响技术选型，比精确数字更重要。

先定容量，再定方案 — PROCESSING

requirements.log

// 容量估算
const estimates = {
  dailyActiveUsers: 100_000_000,     // 1 亿 DAU
  linksPerUserPerDay: 1,
  readWriteRatio: 100,               // 读:写 = 100:1

  // 写 QPS
  writeQPS: Math.ceil(100_000_000 / 86_400),  // ~1157 次/秒

  // 读 QPS
  readQPS: 1157 * 100,               // ~115,700 次/秒

  // 存储估算（5 年）
  totalLinks: 1157 * 86_400 * 365 * 5,  // ~182 亿条
  avgRecordSize: 500,                 // bytes（URL + 元数据）
  totalStorage: 182_000_000_000 * 500,  // ~91 TB

  // 短码长度：Base62, 6 位 = 62^6 = 568 亿种
  shortCodeLength: 6,
  maxCodes: 62 ** 6,  // 56_800_235_584 ≈ 568 亿
}

// 结论：
// - 读多写少（100:1）→ 重度缓存
// - 91TB 存储 → 数据库分片
// - 568 亿短码空间 → 6 位足够 5 年

需求分析：系统设计第一步：量化需求。日活 1 亿用户，每人每天生成 1 个短链 → 写 QPS 约 1157（100M/86400）；每个短链平均被访问 100 次 → 读 QPS 约 11.6 万。数据保存 5 年 → 约 1825 亿条记录 → 约 18TB 存储。这决定了架构的核心约束。

实时沙盒SANDBOX

CRITICAL

快速场景

手动调节

读 QPS

重定向请求量

100k次/秒

Redis 缓存可承载，命中率 > 99%

缓存命中率

影响 DB 实际承受的 QPS

99%

大量缓存穿透，DB 面临崩溃

数据库分片数

分片越多，单片数据越少

16 分片，读写均衡，扩容方便