短链接生成 API 系统是如何设计的？
——以「快缩短网址」suo.run 为例

一、缘起：从冗长到轻盈
一条原始 URL 可能长达数百字符，既占空间又显臃肿，更遑论在 140 字的微博或 70 字的短信里安家落户。于是，短链接应运而生：它像一枚轻巧的琥珀，封存了原址的全部信息，却只留下几粒晶莹的字符。

二、核心目标
1. 极致压缩：长度 ≤ 7 位，永不重复。
2. 毫秒级响应：生成、跳转皆在 50 ms 内完成。
3. 可观测：每一次点击都化作可溯源的数据。
4. 可扩展：日活千万，水平扩容不宕机。

三、系统架构纵览
┌────────────┐
│ Client（App/Web） │
└──────────┬─────────┘
│ HTTPS
┌──────────┴─────────┐
│ API Gateway（Kong）│ 限流 / 鉴权 / 日志
└──────────┬─────────┘
│ gRPC
┌──────────┴─────────┐
│ Shorten Service │ 生成短码、防碰撞
└──────────┬─────────┘
│ Redis / MySQL
┌──────────┴─────────┐
│ Redirect Service │ 301 跳转、统计回写
└──────────┬─────────┘
│ Kafka
┌──────────┴─────────┐
│ Analytics Service │ 实时漏斗、渠道归因
└────────────────────┘

四、短码生成算法
1. 预置 62 进制字符池（0-9a-zA-Z）。
2. 全局发号器：Snowflake 变种，保证 64 bit 内有序、无冲突。
3. 哈希增强：对原始 URL 再做 MurmurHash，避免顺序猜测。
4. 布隆过滤器：在 1 ms 内完成「是否已存在」判断，99 % 命中率。

五、存储策略
• 热数据：Redis String「短码 → 原始 URL」，TTL 7 天，LRU 兜底。
• 冷数据：MySQL 分库分表，按短码首字母 64 张表，索引覆盖查询。
• 归档：7 天后异步转存 TiDB，支持秒级 OLAP。

六、跳转流程
1. 浏览器访问 https://suo.run/AbC123
2. Nginx 直接透传至 Redirect Service。
3. Redirect Service 先查 Redis，未命中则回源 MySQL。
4. 返回 301 + Cache-Control: max-age=300。
5. 同时异步写 Kafka Topic「click」，供下游实时归因。

七、API 设计
POST /api/v1/shorten
Content-Type: application/json

{
"url": "https://example.com/very/long/path?utm=...",
"alias": "可选自定义短码",
"expire_days": 30,
"channel": "sms"
}



返回
{
"short": "https://suo.run/AbC123",
"qr": "https://suo.run/qr/AbC123.png",
"ttl": 2592000
}

八、安全与风控
• 域名黑名单：同步 Google Safe Browsing + 自建钓鱼库，秒级拦截。
• 频率限制：IP 10 次/分钟，Token 1000 次/小时。
• 自定义短码白名单：仅企业版可指定，防止品牌劫持。

九、可观测体系
• Prometheus + Grafana：QPS、P99 延迟、错误率。
• Jaeger 全链路追踪：从网关到存储，一次请求 8 个 Span。
• 实时看板：渠道 UV、转化率、异常告警飞书推送。

十、水平扩容秘籍
1. 无状态服务：Shorten & Redirect 容器化，K8s HPA 按 CPU 50 % 弹性。
2. 发号器双写：Snowflake 节点 + 号段模式，宕机 3 s 内切换。
3. Redis Cluster：三主三从 + 哨兵，跨 AZ 双活。

十一、未来演进
• 边缘节点：基于 Cloudflare Workers 的全球 300+ POP 跳转，延迟 < 10 ms。
• 智能跳转：根据用户 UA、地域、时段，A/B 测试不同落地页。
• 零知识短链：使用可验证延迟函数（VDF）隐藏原始 URL，防爬虫溯源。



结语
一条短链，不过寥寥数笔，却承载着流量、品牌与安全的千钧之重。在「快缩短网址」suo.run，我们用简洁的字符，雕刻出互联网最优雅的通行证。