系统设计题

2026-04-281 出链1 引用
CS

先问这个系统现在到底在对抗什么Scale：Traffic、Data，还是 Failure？

  • S：在学习和实践“系统设计题”时，需要建立统一的概念和问题边界。

  • C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。

  • Q：“系统设计题”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？

  • A：本文围绕“系统设计题”整理核心概念、关键机制和工程实践，并明确其适用边界。各类系统的可复用模式见 系统设计范式速查。

  • S 场景（Scenario）：明确系统服务的用户群体、核心功能、典型使用场景。例如设计短链系统时，用户是普通网民，核心功能是生成/跳转短链，场景是社交平台分享长链接。

  • C 冲突（Conflict）：识别系统面临的核心矛盾与约束。例如短链系统需支撑高并发读（跳转请求远多于生成请求）、持久化存储短链映射、低延迟响应。

  • Q 问题（Question）：拆解为可量化的技术问题。例如：需要多少存储？平均/峰值QPS是多少？缓存如何设计？

  • A 回答（Answer）：输出具体设计方案、量级估算、组件拆分、瓶颈分析与应对。

怎么从我要设计一个系统落到这个系统大概要多少机器、多少存储、怎么拆组件、哪里会成为瓶颈

系统设计不是背组件，而是根据规模和业务约束，在延迟、吞吐、一致性、可用性、成本和复杂度之间做取舍。

从需求到落地的核心流程

上述问题的解答核心分5步：

  1. 需求澄清：明确功能需求（核心功能边界）、非功能需求（可用性、一致性、延迟、成本等）、约束条件（如团队技术栈、合规要求）。
  2. 量级估算：基于DAU/MAU等指标计算QPS、存储、带宽等核心参数（详见下方估算指标说明与示例）。
  3. 高层设计：拆分核心组件（接入层、业务层、数据层、中间件层），梳理组件间交互关系，输出架构图。
  4. 详细设计：确定各组件技术选型（如数据库用MySQL/NoSQL、缓存用Redis/Memcached）、数据模型、接口定义、一致性方案。
  5. 瓶颈与扩展：识别潜在瓶颈（如数据库读压力、存储不足），给出扩展方案（如加缓存、分库分表、分布式存储），并估算所需资源（机器数、存储量等）。

常见估算指标：重点是数量级

1. DAU / MAU

  • 定义：每日活跃用户 / 每月活跃用户
  • 估算：MAU ≈ DAU × 30 × 留存率（通常取0.3~0.5），即 DAU ≈ MAU × (1/30 ~ 1/15)
  • 示例：MAU=1亿，则 DAU≈3000万~7000万

2. QPS（Queries Per Second）

  • 定义：每秒请求数
  • 估算：QPS = DAU × 人均日请求数 / 86400
  • 示例：DAU=1000万，人均日请求20次 → QPS = 1000万×20/86400 ≈ 2300

3. Peak QPS（峰值QPS）

  • 定义：峰值 QPS
  • 估算：Peak QPS ≈ 平均QPS × 峰值系数（通常取3~5，取决于业务特性）
  • 示例：平均QPS=2000，峰值系数=3 → Peak QPS=6000

4. Read / Write Ratio（读写比例）

  • 定义：读写请求比例
  • 典型值：读多写少场景（如新闻、电商详情）可达 100:1；读写均衡场景（如IM）约 2:1
  • 影响：决定缓存策略、数据库主从配置

5. Storage（存储量）

  • 定义：存储量
  • 估算：存储量 = 单条数据大小 × 日新增量 × 保留天数
  • 示例：短链系统，每条记录100B，日新增100万条，保留1年 → 100B×100万×365 ≈ 36.5GB

6. Bandwidth（带宽）

  • 定义：带宽
  • 估算：入带宽 = 写QPS × 单请求大小；出带宽 = 读QPS × 单响应大小
  • 示例：读QPS=2000，单响应1KB → 出带宽 = 2000×1KB = 2MB/s ≈ 16Mbps

7. Cache Size（缓存容量）

  • 定义：缓存容量
  • 估算：缓存量 = 热点数据量 × 缓存比例（通常缓存20%热点数据可覆盖80%请求）
  • 示例：总数据100GB，热点20% → 缓存需20GB

8. Message Throughput（消息吞吐）

  • 定义：消息吞吐
  • 估算：消息数/秒 = 用户数 × 人均消息频率
  • 示例：IM系统，100万在线用户，人均每分钟1条消息 → 100万/60 ≈ 1.67万条/秒

9. Database Rows（数据库行数增长）

  • 定义：数据库行数增长
  • 估算：日增长行数 = 日新增记录数；年增长 = 日增长 × 365
  • 示例：日新增订单10万 → 年新增3650万行，需考虑分库分表

系统设计示例：短链系统

S 场景

设计一个类似 bit.ly 的短链服务，用户提交长链接，系统返回短链；其他用户访问短链时跳转到原始长链接。

C 冲突

  • 高并发读（跳转请求 >> 生成请求）
  • 短链需全局唯一且尽可能短
  • 低延迟跳转（<100ms）
  • 数据持久化且可统计点击量

Q 问题

  • 日生成短链100万，日跳转1亿次，读写比100:1
  • 需要多大存储？
  • 平均/峰值QPS多少？
  • 如何保证短链唯一性？
  • 缓存如何设计？

A 回答

量级估算：

  • DAU: 1000万（假设），生成短链100万/天，跳转1亿/天
  • 平均写QPS = 100万/86400 ≈ 12；读QPS = 1亿/86400 ≈ 1157
  • Peak读QPS ≈ 1157 × 3 = 3471
  • 存储：每条记录100B，日100万条，保留1年 → 100B×100万×365 ≈ 36.5GB
  • 缓存：热点20%数据（7.3GB），用Redis

高层设计：

用户 → API Gateway → 短链服务 → 数据库（MySQL）
                           ↓
                        Redis缓存

详细设计：

  • 短链生成：雪花算法或自增ID转Base62
  • 缓存：Redis缓存热点短链映射，TTL 24小时
  • 数据库：MySQL存储映射关系，按短链hash分表
  • 跳转：先查缓存，未命中查DB，异步记录点击日志

瓶颈与扩展：

  • 瓶颈：数据库读压力（已用缓存缓解）
  • 扩展：缓存集群、数据库读写分离、CDN加速跳转

评论