TRAE Learning

系统设计 ​

难度：⭐⭐⭐⭐ 高级 | 预计时间：3 小时

系统设计是 AI 真正能改变工作方式的领域之一。不是因为 AI 能替你做决定，而是它能成为一个不知疲倦的讨论对象——帮你把模糊的想法变成清晰的方案。

这个教程用"设计一个短链服务"作为例子，展示如何用 Trae 辅助整个设计过程。

从模糊需求开始 ​

大多数系统设计从一句话开始："我们需要一个短链服务"。把这个直接抛给 Trae：

我要设计一个短链服务，大概和 bit.ly 类似：
- 输入长 URL，生成一个短链
- 访问短链，302 跳转到原始 URL
- 需要统计点击次数

请问我几个关键问题，帮我理清需求。

让 AI 提问，而不是直接给你答案。这个过程会暴露你没想清楚的地方：预计的 QPS 是多少？短链是永久的还是有有效期？需要自定义短链码吗？

第一步：估算规模 ​

同样的功能，100 QPS 和 100,000 QPS 的实现方案完全不同。先做量级判断：

帮我做个量级估算：
- 日活 100 万用户
- 平均每人每天生成 1 条短链，访问 10 次
- 短链保留 3 年

估算存储量、QPS、带宽需求

拿到数字之后，你会知道这个规模是用单机 SQLite 就够了，还是需要分布式方案。

第二步：设计数据模型 ​

基于刚才的量级，设计短链服务的数据库模型：
- 用 PostgreSQL
- 需要存哪些字段？用什么数据类型？
- 短链的唯一 ID 怎么生成？（自增 ID 转 Base62 vs 随机字符串 vs 哈希）
- 需要哪些索引？

重点不是让 AI 给你"标准答案"，而是理解每个设计决策背后的理由。每当 AI 给出一个选择，问它"如果用另一种方式，会有什么问题"。

第三步：讨论关键决策点 ​

每个系统都有几个核心的 trade-off。对短链服务来说：

短链生成算法：

短链 ID 生成常见的三种方案：
1. 自增 ID 转 Base62
2. 随机生成 6 位 Base62 字符串
3. 对原始 URL 做哈希取前几位

在我们的场景下（日活 100 万，短链不能被预测），分析各自的优缺点

缓存策略：

我们的读写比大概是 10:1，访问热点分布不均匀（有些短链会突然很热）

讨论一下要不要加缓存，如果加：
- 用什么缓存（Redis vs 本地内存）
- 缓存什么数据
- 缓存失效策略

第四步：整理方案并实现核心路径 ​

讨论清楚之后，选最核心的部分先实现：

用 Node.js + Express + PostgreSQL 实现短链服务的核心功能：
- POST /shorten — 接收长 URL，生成短链码，存入数据库，返回完整短链
- GET /:code — 查询数据库，记录点击次数，302 重定向到原始 URL

先不考虑缓存和限流，把核心链路跑通

跑通之后，你已经有了一个可以演示的版本。后续的优化（缓存、限流、自定义短链）可以一个个迭代加进去。

下一步 ​