Reference · 001 · 持续更新
系统设计词典
每一课首次出现术语时标注英文，此后一律使用这里的译名。按主题分组，共 5 组。
一 ·需求与质量属性
- 功能需求 Functional Requirements
- 系统「做什么」：核心用例与功能边界。四步框架第 1 步产出之一。
- 非功能需求 Non-functional Requirements
- 系统「做得多好」：规模、延迟、可用性、一致性约束。系统设计的本质是满足非功能需求（DDIA 2e 以此开篇）。
- 可用性 Availability
- 服务正常时间占比，用「几个 9」表示：99.9% ≈ 年停机 8.76h；99.99% ≈ 52.6 分钟；99.999% ≈ 5.26 分钟。
- 可扩展性 Scalability
- 加资源就能成比例承载更多负载的能力。区分纵向扩展（换更强机器）与横向扩展（加更多机器）。
- 可靠性 Reliability
- 系统在约定条件下持续正确工作的程度——「少出事」；可用性是「挂了多久」，可靠性还包含数据正确性。
- 一致性 Consistency
- 多个副本对同一数据的读取结果在多大程度上保持一致。谱系：线性一致 → 顺序一致 → 因果一致 → 读己之写 → 最终一致。
- 权衡 Trade-off
- 不存在没有代价的选择；资深工程师的标志是能明确说出「选 A 代价是 X，选 B 代价是 Y，本场景 X 更可接受」。
- 服务水平协议 SLA / SLO
- SLA：对外承诺（含违约赔偿）；SLO：内部目标（如月度可用性 99.95%）。容量与架构围绕 SLO 设计。
二 ·流量与性能
- 每秒请求数 QPS / RPS
- 每秒处理的请求量。估算：DAU × 人均日操作 ÷ 86400。类似：TPS（每秒事务）。
- 吞吐量 Throughput
- 单位时间处理的数据量或任务量（MB/s、条/秒）。与延迟相互制约。
- 延迟 Latency
- 处理单个请求的时间。必须看分布而非平均值——见「长尾延迟」。
- 百分位延迟 P50 / P95 / P99
- P99 = 99% 的请求快于此值。优化 P99 叫「治理长尾」：慢的 1% 往往由 GC、抖动、热 key 造成。
- 日活用户 DAU
- 每天至少使用一次产品的用户数，容量估算的起点。
- 读多写少 / 写多读少 Read-heavy / Write-heavy
- 读写比决定主战场：读多 → 缓存是第一杠杆；写多 → 队列、批量写、分片是方向。
- 峰值系数 Peak Factor
- 峰值与均值 QPS 之比，常取 2–3（晚高峰/大促）。容量按峰值规划，成本按均值理解。
三 ·架构组件
- 负载均衡器 Load Balancer / LB
- 把请求分发到多台后端并提供健康检查。L4（TCP 层转发）与 L7（可看 URL/Header）两类。
- 无状态服务 Stateless Service
- 服务实例不保存会话/用户状态（状态外置到 Redis 等），任何实例等价——横向扩展与弹性伸缩的前提。
- 会话粘连 Sticky Session
- LB 把同一用户固定到同一实例。是无状态化之前的补丁，破坏负载均匀性。
- 健康检查 Health Check
- LB 定期探测后端存活并剔除故障节点。检查阈值过松/过严都是真实事故来源。
- 内容分发网络 CDN
- 把静态内容复制到全球边缘节点就近服务，绕过光速限制。Pull（按需回源）与 Push（主动预推）两种模式。
- 反向代理 Reverse Proxy
- 代表服务端接收请求的中间层（如 Nginx）：可承担 LB、TLS 终结、缓存、压缩。
- 主从复制 Leader-Follower Replication
- 写全走主库，变更日志同步从库；读可分流。主流拓扑另有多主（写冲突）与无主（quorum 仲裁）。
- 复制延迟 Replication Lag
- 从库落后主库的时间差。引发读己之写被破坏（改完刷新看不到）。
- 读己之写 Read-your-writes
- 用户至少能读到自己刚写的数据。解法：关键读走主库、会话级粘连。
- 单调读 Monotonic Reads
- 同一用户看到的版本不回退（不会越刷越旧）。实现：同一用户粘连同一副本。
- 数据按分片键水平切分到多机。解决写扩展与单机容量，代价：跨片查询/事务困难。
- 分片键 Sharding Key
- 决定数据归属的键。三条标准：高基数、与高频查询对齐、抗倾斜。选定后极难更改。
- 数据倾斜 Data Skew
- 某些分片/键的数据量或流量远超均值（大 V、爆款、机场格子）。解法：二次拆分、热点隔离。
- 一致性哈希 Consistent Hashing
- 节点与 key 放到哈希环上顺时针寻址；增删节点只迁移约 K/N 数据（取模则几乎全部）。
- 虚拟节点 Virtual Nodes / Vnodes
- 每个物理节点在环上放 N 个影子位置：分布更均匀，可按算力加权（Dynamo/Cassandra 做法）。
- 缓存 Cache
- 热点数据放更快介质（内存）。把读从 SSD 层（~100µs）搬到内存层（~100ns），一次就是 1000 倍。
- 缓存命中率 Cache Hit Ratio
- 缓存挡住的读请求占比。核心指标：每降 1%，回源流量升约 10%。
- 缓存穿透 Cache Penetration
- 查询不存在的数据，永不命中，全部打 DB。解法：空值短 TTL、布隆过滤器。
- 缓存击穿 Cache Breakdown
- 单个热点 key 过期瞬间，并发全部回源重建。解法：互斥重建、逻辑过期。
- 缓存雪崩 Cache Avalanche
- 大量 key 同时过期或缓存集群宕机。解法：TTL 抖动、集群 HA、熔断降级兜底。
- 布隆过滤器 Bloom Filter
- 概率集合：说「没有」一定没有（可放心拦截），说「有」可能误报。O(1) 空间换误判率。
- 消息队列 Message Queue / MQ
- 生产者与消费者间的异步缓冲（Kafka 等）：削峰、解耦、重试缓冲。代价：最终一致 + 运维复杂度。
- 削峰填谷 Peak Shaving
- 瞬时洪峰进队列排队，消费者按稳定速率处理——用排队时间换系统存活。
- 消费者组 Consumer Group
- 一组消费者共同消费一个 topic，分区内消息只给组内一个消费者；不同组各自独立消费全量。
- 死信队列 Dead Letter Queue / DLQ
- 重试 N 次仍失败的消息的归宿：隔离毒丸、人工处理，保主流程继续。
- 消息积压 Lag
- 未消费消息的堆积量——系统债务，只增不减时必须告警、扩消费者或降级上游。
四 ·一致性与容错
- CAP 定理 CAP Theorem
- 一致性、可用性、分区容忍三者最多取二。P 不可避免，真实取舍在分区时：CP（拒写保一致）还是 AP（续服保可用）。
- PACELC
- CAP 的补充：即使无分区（Else），也要在延迟（Latency）与一致（Consistency）间取舍——强一致要等副本确认，每步都是 RTT。
- 仲裁 Quorum
- N 副本中写 w 个确认、读 r 个，w + r > N 则读写集合有交集、可读到最新。r、w 是「一致↔延迟」的旋钮。
- 线性一致 Linearizability
- 最强单对象保证：操作像单机上串行发生，读永远最新。实现靠共识算法（Raft），代价是延迟与可用性。
- 因果一致 Causal Consistency
- 有因果关系的操作全节点同序（回复不能先于被回复出现）。比线性一致便宜得多。
- 最终一致 Eventual Consistency
- 停止写入后副本最终收敛。适用于点赞数、短码复制、feed 流等「旧一点没关系」的数据。
- 选主 Leader Election
- 主库宕机后提升新主。风险是脑裂（split brain，双主双写）——工业解法：Raft 类多数派算法。
- 限流 Rate Limiting
- 超过容量的请求快速拒绝（429 + Retry-After），好过全系统排队慢慢死。见限流算法速查表。
- 令牌桶 Token Bucket
- 恒速放令牌、请求取令牌：速率 r 控长期平均，桶深 S 控突发额度。工业首选。
- 熔断器 Circuit Breaker
- 下游故障时快速失败停止调用（Closed→Open→Half-Open 三态），防级联失败。
- 舱壁隔离 Bulkhead
- 为不同依赖分配独立资源池（线程/连接），一个依赖拖垮不殃及全局。
- 降级 Graceful Degradation
- 资源不足时主动舍弃非核心（关推荐、返回静态兜底、读旧缓存），保住交易主链路。
- 指数退避 Exponential Backoff
- 重试间隔按 1s、2s、4s… 翻倍。不加退避的重试会形成重试风暴放大故障。
- 抖动 Jitter
- 给定时/过期/退避加随机偏移，避免大量事件「齐步走」（同时过期=雪崩、同时重试=风暴）。
- 幂等 Idempotency
- 同一操作执行多次与一次效果相同。至少一次投递下消费者必备：唯一 ID + 去重表 / upsert 写入。
- 单点故障 Single Point of Failure / SPOF
- 挂掉即全局不可用的组件。设计第 4 步必查清单：LB、主库、发号器、注册中心……都要冗余。
五 ·系统模式与案例术语
- 扇出写 / 扇出读 Fan-out on Write / Read
- feed 流两种路线：写时推送到所有粉丝收件箱（读快、大 V 写爆炸）vs 读时现场合并关注列表（写简单、读贵）。工业答案：混合推拉。
- 雪花 ID Snowflake ID
- 时间戳+机器ID+序列号的全局唯一 ID：趋势递增，ID 排序即时间排序（timeline 依赖此性质）。
- 号段模式 Segment ID Allocation
- 发号器一次发一段 ID 给应用服务器本地使用，用完再领——把 DB 发号压力降两个数量级。
- base62
- 0-9a-zA-Z 的 62 进制编码，7 位可表 3.5 万亿——短链短码的标准编码。
- 自适应码率 Adaptive Bitrate
- 视频切成分片 + 多档清晰度索引（HLS/DASH），播放器按网速逐片换档。
- 转码 Transcoding
- 把上传的原始视频转成多档清晰度格式——离线批任务，MQ 解耦、worker 可扩展。
- 冷热分层存储 Data Tiering
- 热数据 SSD/NVMe、温数据机械盘、冷数据归档——按访问频率购买介质速度（L2 数字感的直接应用）。
- 对象存储 Object Storage
- 按 key 存文件的无限容量存储（S3 类），视频/图片/备份的归宿；配合签名 URL 防盗链。
- 地理网格 Geohash / H3
- 把地球切成可哈希的网格单元：附近搜索 = 查相邻格子。H3 用多分辨率六边形（Uber 提出）。
- 事务性发件箱 Transactional Outbox
- 业务数据与「待发消息」同库同事务落盘，再由后台 relay 发到 MQ——解决「DB 成功了、MQ 丢了」。
- 架构决策记录 Architecture Decision Record / ADR
- 一页纸记录：背景约束 → 备选与权衡 → 决策 → 后果与重评触发条件。四步框架的工作文档形态，晋升答辩素材。
术语有疑问？随时把问题丢给老师（ZCode agent），词条可以现场讨论后追加。