{"name":"分布式","id":"软件工程-架构-系统设计-分布式-分布式","content":"# 分布式系统\n\n## 分布式系统的第一性原理\n\n### 分布式系统的本质问题\n\n分布式系统的本质问题只有一个：\n\n> **状态、顺序的一致性问题**\n\n即：\n\n* 多个节点各自独立运行\n* 没有全局时钟\n* 通过不可靠网络通信\n\n在这样的环境中，系统如何：\n\n* 判断“当前状态是什么”\n* 判断“谁是对的”\n* 判断“事情是否已经发生”\n\n### 为什么必须引入分布式\n\n分布式系统的存在，源于：**用户日益增长的高可用、低延迟、海量数据需求** 与 **单机算力、存储、网络上限之间的矛盾**\n\n这一矛盾驱动的**必然选择**：\n\n* **计算规模扩大**：单机性能与成本不再线性\n* **数据规模增长**：状态无法放入单一节点\n* **可用性要求提高**：任何单点都不可接受\n* **组织协作需求**：系统必须支持并行演进\n\n## 不可靠世界：分布式系统的基本假设\n\n分布式系统的所有复杂性，来源于一个前提：\n\n> **我们生活在一个不可靠的世界中。**\n\n这一不可靠性体现在三个不可消除的维度。\n\n### 网络不可靠：通信不确定性\n\n节点之间只能通过消息协作，但网络具备以下特性：\n\n* 消息可能延迟\n* 消息可能丢失\n* 消息可能重复\n* 无法区分“慢”与“死”\n\n因此：\n\n> **分布式系统中不存在“确定的通信”，只存在“推测”。根本原因是发送方只能通过响应推断对方的状态**\n\n#### 超时：主要的判断机制\n\n* 系统无法知道消息是否还会到达\n* 只能在等待一段时间后做出判断\n* 超时不是精确科学，而是统计选择\n\n> 超时并不代表失败，而是**系统做出的一个假设**。\n\n### 节点不可靠：部分失效成为常态\n\n分布式系统中，失效不是”全有或全无”，而是：\n\n> **部分节点在部分时间失效**（Partial Failure）\n\n常见失效模型：\n\n* **崩溃-中止故障**：节点停止响应\n* **崩溃-恢复故障**：节点可能在未知时间后恢复\n* **拜占庭故障**：节点行为不可预测\n\n工程实践中通常假设：\n\n> **非拜占庭故障模型**，以换取系统复杂度的可控性。\n\n### 时间不可靠：不存在全局时间\n\n计算机中的时间具备以下特征：\n\n* 本地时钟会漂移\n* 时钟同步存在误差\n* 进程可能被任意暂停（STW / 调度）\n\n因此：\n\n> **时间顺序无法作为分布式系统的可靠依据。**\n\n#### 两类时间认知\n\n* **物理时间**：有意义但不可靠（NTP）\n* **逻辑时间**：无物理含义但顺序可靠\n\n分布式系统必须优先使用**逻辑顺序**而非物理时间。\n\n## 我们能做的唯一事情：假设与多数\n\n在不可靠世界中，分布式系统能依赖的能力极其有限。\n\n### 多数原则（Quorum）\n\n> 当一个状态被**多数节点认可**时，我们将其视为”当前真相”。\n\n* 多数不是正确性的保证\n* 而是**系统能达成的最强一致假设**\n\n这是共识算法、选主机制、一致性存储的共同基础。\n\n### 假设驱动的系统设计\n\n分布式系统并不”知道事实”，而是：\n\n* 基于超时做假设\n* 基于多数做裁决\n* 基于版本做冲突判断\n\n> **分布式系统是一个持续修正假设的系统。**\n\n## 一致性模型：对状态一致性的不同承诺\n\n一致性并非非黑即白，而是一条连续谱。\n\n### 一致性不是目标，而是代价函数\n\n> 一致性越强：\n>\n> * 延迟越高\n> * 可用性越低\n> * 系统越复杂\n\n### 常见一致性模型谱系\n\n| 一致性模型 | 本质承诺    | 代价   | 典型场景  |\n| ----- | ------- | ---- | ----- |\n| 线性化   | 单一时间线幻觉 | 可用性  | 锁、选主  |\n| 顺序一致  | 全局操作顺序  | 延迟   | 日志系统  |\n| 因果一致  | 因果关系保序  | 复杂度  | 协作系统  |\n| 最终一致  | 状态最终收敛  | 冲突处理 | 大规模存储 |\n\n### 线性化的本质\n\n线性化的核心目标是：\n\n> **让系统看起来像只有一个副本。**\n\n其实现方式本质是：\n\n* 复制算法\n* 共识算法\n* 仲裁协议\n\n## 顺序与逻辑时间\n\n### 因果关系是唯一可靠的顺序来源\n\n* 如果 B 依赖 A，则 A → B\n* 不存在因果关系的事件，其顺序无意义\n\n### 逻辑时钟\n\n* Lamport 时钟\n* 版本号 / 任期号\n\n逻辑时钟解决的不是”什么时候发生”，而是：\n\n> **谁先于谁发生。**\n\n## 共识：分布式系统的中枢能力\n\n### 共识的角色\n\n共识解决的是：**系统对同一状态是否达成一致判断。**\n\n其工程形式通常是：\n\n* 状态机复制\n* 主节点选举\n* 日志一致提交\n\n### 全序广播\n\n全序广播的目标是：\n\n* 消息不丢失\n* 所有节点看到相同顺序\n\n这是构建一致状态机的基础能力。\n\n## 工程能力模型：从工具到能力\n\n| 架构能力 | 对抗问题 | 常见手段   |\n| ---- | ---- | ------ |\n| 扩展性  | 规模增长 | 分片、无共享 |\n| 可用性  | 节点失败 | 副本、选主  |\n| 稳定性  | 瞬时冲击 | 限流、降级  |\n| 一致性  | 状态分歧 | 共识、版本  |\n\n\n## 分布式系统的工程哲学\n\n### 反直觉事实\n\n* 失败是常态，而非异常\n* 超时不是失败，而是判断\n* 不一致并不等于错误\n* 可用性是设计出来的\n\n### 设计取舍\n\n> 分布式系统不是\"选择正确方案\"，\n> 而是**明确你愿意付出的代价**。\n\n## 适用边界\n\n### 核心原则：代价先验\n\n分布式架构的**本质是代价交换**，而非能力增强。引入分布式之前，必须明确你愿意为之付出的代价。\n\n### 驱动因素：为什么必须分布式\n\n只有以下力量能驱动分布式架构的引入——缺少任何一个，分布式就是过度设计：\n\n| 驱动力 | 本质 |\n|-------|------|\n| **规模压力** | 单机算力/存储/带宽无法承载业务量 |\n| **可用性要求** | 单点故障不可接受，业务中断代价极高 |\n| **独立演进** | 业务领域边界清晰，需并行开发与发布 |\n| **地域分布** | 用户或数据有物理位置约束 |\n\n### 主要代价\n\n分布式系统引入的代价是**不可消除的根本性成本**：\n\n- **延迟**：跨网络调用比进程内调用更高\n- **一致性**：发生网络分区时，强一致性与高可用性不可兼得（CAP 约束）\n- **复杂性**：节点增多导致故障定位、版本管理、运维成本指数增长\n- **组织摩擦**：服务边界需要跨团队协调\n\n### 不适用场景的原则判断\n\n以下场景天然不适合分布式，应优先选择单体：\n\n1. **业务规模未超出单机上限** — 分布式解决的是规模问题，规模未达瓶颈时分布式徒增复杂性\n2. **强一致性事务频繁** — 分布式事务的代价极高，频繁跨服务强一致性场景下分布式是反模式\n3. **团队能力或基础设施不足** — 分布式需要配套的 CI/CD、监控、服务治理能力；能力不足时分布式反而降低可靠性\n4. **业务边界模糊** — 服务拆分依赖清晰的领域边界；边界模糊时的分布式拆分只会制造\"分布式单体\"\n\n## 反模式与误区\n\n### 核心认知：不确定性不可消除\n\n分布式系统所有反模式都源于一个事实：**错误必然发生**。\n\n系统的应对方式决定了架构质量，而非避免错误的程度。\n\n### 三个根本性误解\n\n| 误解 | 真相 |\n|------|------|\n| 可以消除不确定性 | 只能管理，无法消除 |\n| 一致性是可选特性 | 一致性是代价函数，越强代价越大 |\n| 存在\"正确\"算法 | 所有算法都是权衡，无银弹 |\n\n### 常见反模式\n\n| 反模式 | 核心问题 | 典型后果 |\n|--------|----------|----------|\n| 分布式单体 | 服务间高耦合 | 改一处动全身 |\n| 级联故障 | 故障扩散 | 雪崩 |\n| 过度信任超时 | 超时≠失败 | 重复操作、幂等破坏 |\n| 一致性模型错配 | 场景与一致性不匹配 | 支付丢数据 / Feed响应慢 |\n| 循环依赖 | 调用环 | 局部故障→全链路瘫 |\n| 无界重试 | 故障流量无管控 | 下游过载 |\n\n## 关联内容（自动生成）\n\n- [/软件工程/架构/系统设计/分布式/分布式理论.md](/软件工程/架构/系统设计/分布式/分布式理论.md) 深入探讨了CAP定理、BASE理论等分布式系统的基本理论，与本文的原理驱动设计思想高度相关\n- [/软件工程/架构/系统设计/分布式/分布式数据.md](/软件工程/架构/系统设计/分布式/分布式数据.md) 详细分析了分布式数据存储、复制和分区策略，是对分布式系统原理的具体实现\n- [/软件工程/架构/系统设计/分布式/分布式一致性系统.md](/软件工程/架构/系统设计/分布式/分布式一致性系统.md) 从制度化管理角度分析分布式一致性，与本文对状态一致性的探讨形成互补\n- [/软件工程/架构/系统设计/分布式/分布式一致性与协调机制.md](/软件工程/架构/系统设计/分布式/分布式一致性与协调机制.md) 从协调机制角度深入分析锁、Session、事务等与共识的互补关系\n- [/软件工程/架构/系统设计/分布式/分布式共识算法.md](/软件工程/架构/系统设计/分布式/分布式共识算法.md) 详细介绍了Paxos、Raft等共识算法，是实现分布式系统一致性的核心技术\n- [/软件工程/架构/系统设计/分布式/分布式事务.md](/软件工程/架构/系统设计/分布式/分布式事务.md) 探讨了分布式事务的实现方案，是分布式系统中保证数据一致性的关键实践\n- [/软件工程/架构/系统设计/高并发.md](/软件工程/架构/系统设计/高并发.md) 高并发场景下的一致性权衡与分布式系统设计直接相关\n- [/软件工程/架构/系统设计/故障管理.md](/软件工程/架构/系统设计/故障管理.md) 分布式故障处理是节点不可靠性的延伸讨论\n- [/软件工程/架构/系统设计/扩展性.md](/软件工程/架构/系统设计/扩展性.md) 扩展性是分布式系统设计的核心目标之一，与本文探讨的分布式系统设计原则密切相关\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) 可用性是分布式系统设计的重要权衡之一，与CAP定理中的A要素相关\n- [/软件工程/架构/架构.md](/软件工程/架构/架构.md) 物理视图中的分布式部署与网络拓扑是分布式系统的架构映射\n- [/中间件/数据库/分布式数据库.md](/中间件/数据库/分布式数据库.md) 分布式数据库是分布式系统的重要实现，与本文的理论基础相互印证\n","metadata":"tags: ['计算机系统', '分布式系统', '数据库', 'cap定理']\nbooks: [\n  {name: '数据密集型应用系统设计'}\n]","hasMoreCommit":true,"totalCommits":17,"commitList":[{"date":"2026-04-08T14:04:09+08:00","author":"MY","message":"docs(architecture): 添加分布式系统适用边界章节","hash":"fe4410e52c63be9749ffb577c740cce3f34add91"},{"date":"2026-04-07T16:32:37+08:00","author":"MY","message":"docs(distributed): 更新分布式系统原理文档结构和内容","hash":"cc0227faa90c845f1ab956062871ac98d53a17d5"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-10T17:32:30+08:00","author":"MY","message":"docs(分布式): 重构分布式系统文档增加原理驱动设计内容","hash":"408edca54bc144535a9a947b6773837d4bb6c7a8"},{"date":"2024-11-21T15:31:50+08:00","author":"MY","message":"📦分布式","hash":"a1a2e13f9d33f87c0b9111848cc8572f865ff631"},{"date":"2023-01-10T10:47:59+08:00","author":"cjiping","message":"✏️分布式","hash":"74803d45290cb75cc240b4955bb9001427d44463"},{"date":"2022-05-16T22:03:56+08:00","author":"MY","message":"✏️更新 分布式","hash":"fda9373ee57b775223d38cda63e4f85a3f162506"},{"date":"2022-05-15T21:49:18+08:00","author":"MY","message":"✏️更新 分布式","hash":"e995151f6a1bc1adfa6cd6bac42d8cabfaecad8f"},{"date":"2022-05-10T21:11:15+08:00","author":"MY","message":"📦整理 分布式","hash":"aea7ab1472f2213205992b32e3224cbb92bc3163"},{"date":"2022-05-09T21:55:31+08:00","author":"MY","message":"✏️更新 分布式","hash":"0a31cca585e8c7885e76327881cb9bd231b3c5a1"}],"createTime":"2021-03-12T14:59:02+08:00"}