# 短链系统设计方案对比与融合总结

## 一、核心目标

短链系统本质只做两件事：

1. **压缩**：把长网址映射成短字符串。
2. **跳转**：用户访问短链时，准确、快速地返回长链。

围绕这两件事，不同场景会衍生出容量、并发、成本、安全、业务规则等差异。

---

## 二、方案 A：Cloudflare Sproutlink（当前项目）

### 2.1 架构组成

| 组件 | 说明 |
|------|------|
| 边缘运行时 | Cloudflare Worker |
| 数据库 | Cloudflare D1（SQLite） |
| 静态前端 | Vite React SPA，通过 `ASSETS` 绑定由 Worker 直接服务 |
| 短码生成 | D1 单表原子自增 + 线性同余混洗 + Base62 编码 |
| 部署 | Serverless，静态资源不计入 Worker Bundle |

### 2.2 短码生成原理

1. **原子自增序列**：`link_seq` 表保存 `next_id`，每次创建时 `UPDATE ... SET next_id = next_id + 1 RETURNING next_id`。
2. **线性同余混洗**：把顺序的 `seq` 映射到 `[0, 62^4)` 空间，公式为 `index = (A × seq + B) mod 62^4`。
   - `A`：与 `62^4` 互质的乘数（`LINK_MULTIPLIER` secret，默认内置大质数）。
   - `B`：偏移量（`LINK_OFFSET` secret）。
   - 双射特性保证唯一，同时让短码看起来“不连续”。
3. **Base62 编码**：字符集 `0-9A-Za-z`，固定 **4 位**，容量 `62^4 ≈ 1477 万`。
4. **自定义短码**：管理员可指定 1–32 位 `a-zA-Z0-9_-`，但不可为恰好 4 位纯英数字，避免与自动码池冲突。

### 2.3 跳转与规则校验

- 使用 **HTTP 302 临时重定向**，确保每次点击都经过 Worker，便于统计。
- 访问流程：查 D1 → 校验过期/点击上限 → 校验 Geo/设备/浏览器/IP/密码 → 302 跳转并原子递增 `clicks`。

### 2.4 业务规则能力

| 规则 | 实现 |
|------|------|
| 有效期 | `expires_at` 字段 |
| 点击上限 | `max_clicks` 字段 |
| 密码保护 | PBKDF2 哈希，密码页表单验证 |
| Geo 限制 | `request.cf.country` |
| 设备/浏览器 | `User-Agent` + `Sec-CH-UA*` |
| IP 白/黑名单 | `CF-Connecting-IP`，支持 IPv4 CIDR |
| 软删除 | `deleted` 字段 |

### 2.5 优势特点

- **成本极低**：Serverless + D1 + 静态托管，免费/低价套餐即可运行。
- **部署极简**：单人可维护，无需维护服务器、Redis、MySQL 集群。
- **短码最短**：4 位 Base62，对二维码、短信字数敏感场景友好。
- **访问规则丰富**：密码、Geo、设备、浏览器、IP 规则开箱即用，适合私域/营销场景。
- **短码防扫号**：线性同余混洗让相邻创建的短码不是连续递增，提高被遍历的难度。

### 2.6 局限

- **容量有限**：4 位码仅 1477 万，公开大规模服务很快耗尽。
- **读并发依赖 D1**：无独立缓存层，热点短链会直接把压力打到数据库。
- **无缓存穿透防护**：缺少布隆过滤器或空值缓存，面对恶意遍历存在一定风险。
- **Cloudflare 生态绑定**：迁移或私有化部署成本较高。

---

## 三、方案 B：大规模分布式短链设计（经典大厂方案）

### 3.1 架构组成

| 组件 | 说明 |
|------|------|
| 发号器 | 分布式 ID 发号器（MySQL 号段模式 / Redis 自增） |
| 数据库 | MySQL 持久化存储 `code → target_url` |
| 缓存 | Redis 读缓存 |
| 防护 | 布隆过滤器 + 空值缓存 + 网关限流 |
| 跳转状态码 | HTTP 302 |

### 3.2 短码生成原理

1. **分布式 ID 发号器**：为每个长链接分配一个全局唯一、单调递增的数字 ID。
2. **Base62 编码**：把十进制 ID 转换成 62 进制，固定 **6 位**。
   - 字符集 `0-9a-zA-Z`。
   - 容量 `62^6 ≈ 568 亿`，足够公开服务长期运行。
3. **唯一索引兜底**：MySQL 对 `code` 加唯一索引，防止并发冲突。

### 3.3 读链路（高并发重点）

```
用户点击 /abc123
    ↓
网关限流 + WAF
    ↓
Redis 查 sl:abc123
    ├─ 命中 → 直接返回 302
    └─ 未命中 → 布隆过滤器判断
         ├─ 一定不存在 → 直接 404
         └─ 可能存在 → 查 MySQL
              ├─ 存在 → 写入 Redis → 302
              └─ 不存在 → 写短时空值到 Redis → 404
```

### 3.4 写链路

```
用户提交长链
    ↓
参数校验、黑名单域名过滤
    ↓
分布式发号器取号
    ↓
Base62 编码
    ↓
MySQL 插入（唯一索引防冲突）
    ↓
写入 Redis + 布隆过滤器
    ↓
返回短链
```

### 3.5 优势特点

- **容量巨大**：6 位码 568 亿，远超 4 位方案。
- **读性能强**：Redis 缓存扛住读多写少特性，适合热点营销短信/微博场景。
- **生产级健壮**：布隆过滤器防缓存穿透、空值缓存防击穿、网关限流防刷。
- **去 Cloudflare 依赖**：技术栈通用，易于私有化或多云部署。

### 3.6 局限

- **成本高**：需要维护 MySQL、Redis、发号器、网关等多套组件。
- **短码更长**：6 位比 4 位在短信/二维码场景略逊。
- **业务规则薄弱**：标准方案通常只讲“跳转”，缺少密码、Geo、设备等访问控制能力。

---

## 四、两套方案核心差异对比

| 维度 | Sproutlink（Cloudflare） | 大规模分布式方案 |
|------|--------------------------|------------------|
| **短码长度** | 4 位 | 6 位 |
| **容量** | 62⁴ ≈ 1477 万 | 62⁶ ≈ 568 亿 |
| **发号方式** | D1 原子自增 + 线性同余混洗 | 分布式 ID 发号器 |
| **存储** | Cloudflare D1 | MySQL + Redis |
| **读缓存** | 无 | Redis |
| **防缓存穿透** | 无 | 布隆过滤器 + 空值缓存 |
| **并发能力** | 中等，依赖 D1 | 高，依赖 Redis |
| **访问规则** | 丰富（Geo/设备/IP/密码） | 通常无或简单 |
| **部署成本** | 极低 | 较高 |
| **适用场景** | 私域、小团队、个人、轻量营销 | 公开互联网、大厂、海量用户 |

---

## 五、融合后的推荐设计

如果让我从零设计一个**可大可小、可进化的短链系统**，我会把两套方案取长补短：

### 5.1 用大规模方案做底座

- **短码长度**：默认 6 位 Base62，容量 568 亿。
- **发号器**：采用 **MySQL 号段模式**（Segment），每个实例本地批量领号，减少 DB 压力。
- **存储**：MySQL 持久化 + Redis 读缓存。
- **防护**：布隆过滤器 + 空值缓存 + 网关限流。
- **状态码**：统一使用 **302**，保证点击量可统计。

### 5.2 吸收 Sproutlink 的规则引擎

| 规则 | 实现位置 |
|------|----------|
| 有效期 | MySQL `expires_at` + 定时清理任务 |
| 点击上限 | MySQL 原子递增 `clicks` / `max_clicks` |
| 密码保护 | Worker / API 网关，密码页验证后 302 |
| Geo 限制 | CDN 边缘（Cloudflare、阿里云 CDN 等）或网关解析 `CF-IPCountry` |
| 设备/浏览器 | 解析 `User-Agent` + Client Hints |
| IP 白/黑名单 | 网关层，支持 IPv4 / IPv6 / CIDR |
| 自定义短码 | 管理员接口，与自动 6 位码池隔离 |

### 5.3 可选：保留短码混洗能力

在 6 位方案中，可以**可选地**对发号器拿到的顺序 ID 做一次可逆混洗（如线性同余），让短码看起来不连续，提升防扫号能力。注意混洗函数必须保证双射。

### 5.4 最终数据流

**写（生成短链）**：

```
提交长链
 → 校验 + 黑名单过滤
 → 号段发号器取唯一 ID
 → 可选混洗
 → Base62 编码
 → MySQL 写入
 → 写入 Redis + 布隆过滤器
 → 返回 6 位短链
```

**读（访问短链）**：

```
用户访问 /abc123
 → 网关限流/WAF
 → Redis 查缓存
    ├─ 命中 → 规则校验 → 302
    └─ 未命中 → 布隆过滤器
         ├─ 不存在 → 404
         └─ 可能存在 → MySQL 查询
              ├─ 存在 → 写 Redis → 规则校验 → 302
              └─ 不存在 → 写空值缓存 → 404
```

---

## 六、选型建议

| 场景 | 推荐方案 |
|------|----------|
| 个人博客、小团队、私域运营、预算敏感 | **Sproutlink（Cloudflare）** |
| 公开互联网、大厂、营销短信、微博 | **大规模分布式方案（6 位 + 发号器 + Redis）** |
| 希望初期低成本、后期可平滑扩展 | **融合方案**：Worker/D1 起步，用户量增长后迁移到 MySQL + Redis |

---

## 七、一句话总结

> **Sproutlink 是“小而美、功能全、低成本”的私域短链方案；大规模分布式方案是“高容量、高并发、抗攻击”的公开短链标准架构。最优实践是把后者的容量与并发能力，与前者的访问规则引擎结合起来，按需分层演进。**