Skip to content

System Design

学习连接 github

怎么回答系统设计的面试题

第一步：描述使用场景，约束和假设

把所有需要的东西聚集在一起，审视问题。不停的提问，以至于我们可以明确使用场景和约束。讨论假设。

  • 谁会使用它？
  • 他们会怎样使用它？
  • 有多少用户？
  • 系统的作用是什么？
  • 系统的输入输出分别是什么？
  • 我们希望处理多少数据？
  • 我们希望每秒钟处理多少请求？
  • 我们希望的读写比率？

第二步：创造一个高层级的设计

使用所有重要的组件来描绘出一个高层级的设计。

  • 画出主要的组件和连接
  • 证明你的想法

第三步：设计核心组件

对每一个核心组件进行详细深入的分析。举例来说，如果你被问到设计一个 url 缩写服务，开始讨论：

  • 生成并储存一个完整 url 的 hash
  • MD5 和 Base62
  • Hash 碰撞
  • SQL 还是 NoSQL
  • 数据库模型
  • 将一个 hashed url 翻译成完整的 url
  • 数据库查找
  • API 和面向对象设计

第四步：扩展设计

确认和处理瓶颈以及一些限制。举例来说就是你需要下面的这些来完成扩展性的议题吗？

  • 负载均衡
  • 水平扩展
  • 缓存
  • 数据库分片

论述可能的解决办法和代价。每件事情需要取舍。可以使用可扩展系统的设计原则来处理瓶颈。

预估计算量

你或许会被要求通过手算进行一些估算。附录涉及到的是下面的这些资源：

相关资源和延伸阅读

查看下面的链接以获得我们期望的更好的想法：

第 1 层：通用 System Design 基础（和互联网共通）

先保证你能搞定这些“标准菜”：

  • 基本组件：
  • Load balancer、API gateway、cache、message queue、数据库、对象存储
  • 基础概念：
  • 水平 vs 垂直扩展、sharding、replication、CAP、大致知道
  • 常见设计套路：
  • 读多写少用 cache、写多用 log + 异步消费、冷热分层、幂等、重试等

练习建议：

  • 设计：URL 短链、Feed 流、通知系统、统计系统
  • 每次都要能说清楚：
  • QPS / TPS 估算
  • 存储容量估算
  • 高可用方案（多副本、跨机房）

这一层不懂，量化那边的东西也很难讲清楚。

第 2 层：量化/交易场景专门强化

这里给你几个“必练题”，你可以一题一题画架构、说 trade-off：

题 1：设计一个 Market Data Ingestion & Distribution 系统

需求点你要主动问 + 自己补充：

  • Sources：多家交易所 / 数据源，UDP 多播 / TCP
  • 目标：
  • 为策略引擎提供本地共享内存 / 内存队列的行情
  • 为回测系统落盘（原始 tick 或聚合 bar）
  • 重点考点：
  • 如何保证低延迟：
    • 尽量少拷贝、Zero-copy、内存池、批量处理
  • 如何处理乱序 / 丢包 / 重传：
    • 序列号、心跳、gap 请求
  • 如何做多级 cache：
    • 最近 N 档 order book 在内存，历史 tick 在本地磁盘或集中存储
  • 故障场景：
    • 行情接收进程挂了、网络抖动、单一交易所 data center 宕机

题 2：设计一个订单通道 + 实时风控

  • 典型路径： Strategy → Order Gateway → Risk Engine → Exchange
  • 问题你要能回答：
  • 风控是在 本地 还是 集中 做？为什么？
  • 风控规则如何配置 & 热更新？重启吗？
  • 如何保证“风控不过的订单 100% 不会出去”？
  • 如何做到“风控不成为延迟瓶颈”？（预加载、预计算、用 bitset/bitmap 做规则）
  • Failover：一个 order gateway 挂了怎么办？重连 / 重发 / 序号管理？

题 3：设计一个回测 / 研究平台

  • 能说清楚：
  • 历史数据存在哪里（对象存储/分布式 FS/列存）？
  • 回放方式：按时间线回放 tick，策略按统一接口消费
  • 如何支持多策略并行回测？
  • 如何保证“回测结果可复现”：
    • 版本化：数据版本、代码版本、配置版本
    • 输出报告 / 日志

第 3 层：面试看重的“表达套路”

不只是你懂不懂，还看你怎么讲。 你可以固定一个“答题模板”：

  1. 先确认目标 & 约束
  2. Latency 要求？吞吐？可用性？
  3. 交易市场数量？产品数量？数据量大致量级？
  4. 画一个高层架构
  5. 若是交易系统：
    • Strategy Cluster、Order Gateway、Risk、MD Handler、Exchange Adapter
  6. 若是数据系统：
    • Ingestion → Normalize → Storage → Query/Compute
  7. 选一两个关键点深挖
  8. 对量化来说，优先深挖：
    • 延迟关键路径（比如从下单到回报）
    • 风险控制 & 容错场景（比如数据错了、流程挂了怎么办）
  9. 考虑故障与监控
  10. 健康检查、心跳
  11. Metrics（延迟、丢包率、订单拒绝率）
  12. 日志与回放（出了问题能复盘）
  13. 总结 trade-off
  14. 延迟 vs 可用性
  15. 精度 vs 性能
  16. 开发复杂度 vs 系统灵活性

你可以自己练： 找一个问题，比如“设计订单路由系统”，按上面这 5 步写一遍，然后看哪里讲不清楚。

步骤

澄清需求

  • 做什么
  • 功能需求
  • 做多大
  • QPS预期多少