系统设计范式

• S：在学习和实践“系统设计范式”时，需要建立统一的概念和问题边界。
• C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
• Q：“系统设计范式”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
• A：本文围绕“系统设计范式”整理核心概念、关键机制和工程实践，并明确其适用边界。背后的 theory 视角参见 系统的Theory与工程实践，具体题目的落地方法见 系统设计题解法框架。

系统设计范式不是固定答案，而是一组可复用的思考模板。更实用的做法不是上来背组件，而是先问 6 个问题，再进入对应模式。

总览

系统设计范式
├── 1. 数据如何被保存与访问？
│   ├── 数据密集系统
│   ├── 数据检索系统
│   └── 派生数据系统
├── 2. 任务如何被执行？
│   ├── 同步请求响应
│   └── 异步处理系统
├── 3. 用户如何实时交互？
│   └── 即时通讯模式
├── 4. 状态如何保持正确？
│   ├── 内部一致性
│   └── 外部一致性
├── 5. 系统如何组织代码和边界？
│   └── 分层架构
└── 6. 系统如何部署、伸缩和运维？
    └── 云原生架构

1. 数据如何被保存与访问？

数据密集系统

数据密集系统 = 围绕“状态”的存储、流动、复制、查询和一致性设计

S 数据量大，核心问题是存得下、查得快、扩得动，典型如订单、账户、Feed、日志。 C 数据增长、热点、事务范围、冷热分布会同时拉扯容量、延迟和一致性。 Q 数据按什么维度增长？主查询路径是什么？热点在哪？哪些字段必须强一致？ A 常见答案是分库分表、读写分离、缓存、冷热分离、CDC，同步区分 OLTP 与 OLAP。

数据检索系统

数据检索系统 = 为了“找得快、找得准、排得好”而专门设计的数据访问系统。

S 用户不是按主键查，而是按关键词、过滤、排序、聚合查，典型如商品、文档、日志搜索。 C 查询能力越强，索引构建和主库同步成本越高，实时性和相关性也会冲突。 Q 是关键词、模糊、聚合还是向量搜索？可接受多大索引延迟？排序依据是什么？ A 常见答案是主库存权威数据，搜索引擎存检索视图，经 CDC/事件构建索引，并在读路径补详情和权限校验。

派生数据系统

派生数据系统 = 从一个权威事实源，通过日志 / 事件流，构建多个面向查询或业务的读模型。

S 派生数据系统从主数据加工出索引、报表、榜单、特征、物化视图。 C 主数据一变，派生数据就可能落后；下游越多，重建、回放、校验就越重要。 Q 变更从哪里捕获？允许多大延迟？是否支持回放、重建、修复？谁是权威源？ A 常见答案是主库 + CDC/事件流 + 增量计算 + 定期校验，明确对外语义是最终一致。

2. 任务如何被执行？

同步请求响应

S 用户发起请求后必须立刻得到明确结果，典型如登录、查详情、余额查询。 C 调用链越长，尾延迟和失败率越高，但用户又不能接受“稍后再看”。 Q 哪些步骤必须在响应前完成？延迟目标是多少？超时后是失败、降级还是处理中？ A 常见答案是缩短主链路，只保留必要事务，其余步骤异步化或降级。

异步处理系统

用消息 / 任务队列把“必须立刻完成的事”和“可以稍后完成的事”拆开

S 用户不必等待全部流程完成，典型如通知、积分、履约、转码、批处理。 C 上游想快返回，下游又必须可靠完成，于是会遇到重复、乱序、堆积、丢失风险。 Q 哪些步骤可异步？是否要求顺序？如何重试、幂等、补偿、死信？用户怎么感知结果？ A 常见答案是业务落库后通过 Outbox/MQ 驱动后台 Worker，配合幂等、重试、死信和补偿。

3. 用户如何实时交互？

即时通讯模式

即时通讯模式 = 围绕“实时连接 + 消息投递 + 状态同步”设计系统。

S 用户需要低延迟实时交互，典型如单聊、群聊、客服会话、弹幕。 C 消息既要快，又要支持断线重连、离线补拉、多端同步和大群扩散。 Q 要保证哪种顺序？离线消息如何补拉？大群用写扩散还是读扩散？ACK 怎么设计？ A 常见答案是长连接接入、消息先持久化后投递、会话内排序、ACK 补拉、按群规模选择扩散策略。

4. 状态如何保持正确？

内部一致性

内部一致性关心“系统内部有没有矛盾”

S 内部一致性关注系统内部多表、缓存、索引、读库、派生库是否一致。 C 一边追求性能和可扩展，一边又不希望缓存、索引、主库彼此打架。 Q 哪些字段必须强一致？缓存怎么更新？谁是权威源？不一致怎么修复？ A 常见答案是单库事务保局部强一致，Cache-aside、CDC、版本号和校验任务保全局最终一致。

外部一致性

外部一致性关心“系统对外承诺有没有兑现”

S 外部一致性关注本系统和支付、物流、短信、第三方平台之间是否对得上。 C 本地事务覆盖不了外部调用，超时不等于失败，重试又可能造成重复副作用。 Q 外部接口是否支持幂等键和查询？超时后如何判定？是否需要对账和补偿？ A 常见答案是本地先落状态，外部请求带幂等键，回调与主动查询统一走状态机，并用对账兜底。

5. 系统如何组织代码和边界？

分层架构

分层架构 = 用清晰的职责边界，把业务规则、应用编排、技术细节隔离开。

S 业务复杂后，需要明确代码边界，避免规则散落在 Controller、DAO、脚本和定时任务里。 C 分层太少会耦合，分层太多会样板化，真正难的是把规则和基础设施分开。 Q 事务边界在哪？哪些能力属于同一领域？领域模型和持久化模型是否拆开？ A 常见答案是按 Controller、Application、Domain、Repository/Gateway 分层，让编排、规则、存储各司其职。

6. 系统如何部署、伸缩和运维？

云原生架构

云原生架构 = 把系统设计成适合自动部署、自动伸缩、自动恢复、可观测的服务集合。

S 系统上线后要面对发布、扩缩容、故障隔离、观测、容灾等问题。 C 实例会频繁变化，服务想弹性就得无状态，但系统一多，发布和排障复杂度会陡增。 Q 状态放哪？如何扩缩容？如何发布回滚？如何做日志、指标、Trace、告警和容灾？ A 常见答案是容器化 + 无状态服务 + 自动扩缩容 + 灰度发布 + 可观测性 + 多 AZ/备份恢复。

速查表