什么是分布式系统：定义与本质特征

01-基础与模型入门约 15 分钟 #基础#定义#部分失效#无共享更新 2026-10-02

当前状态：未学

本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。

一句话定义

分布式系统是由多个通过网络通信、各自拥有独立内存与独立故障域的计算节点组成，协同对外表现为一个统一服务的系统。

为什么重要

现代互联网服务的规模（亿级用户、PB 级数据）远超单机极限，任何可扩展、高可用的服务必然是分布式的。更重要的是：一旦分布式，单机时代"理所当然"的假设全部失效——没有全局状态、没有全局时钟、故障从异常变成常态。不理解这些本质差异，就无法解释后续所有复杂机制（共识、一致性、事务）为什么存在。

前置知识

操作系统基础（进程/内存模型）、TCP/IP 网络基本概念。

核心概念

节点（node）：一个可独立计算与存储的单元（物理机、虚拟机、容器或进程）。
消息（message）：节点间唯一的交互方式，经网络传递，可能丢失、延迟、乱序、重复。
无共享（shared-nothing）架构：节点不共享内存与磁盘，只靠消息协作——这是分布式系统的主流形态。
部分失效（partial failure）：系统的一部分坏了而另一部分还活着，且对存活部分而言"另一部分坏了"不可立即判定。
不可预测延迟：网络延迟没有可靠上界，等待多久算"对方挂了"没有确定答案。

原理与机制

分布式系统与单机程序的本质区别来自三个"消失"：

全局状态消失：任何节点任一时刻看到的都只是系统的局部视图，聚合全局视图本身需要通信与协调成本。
全局时钟消失：两台机器无法就"现在几点"达成一致，事件先后只能靠消息传递来推断（见 kp-003、kp-004）。
原子故障观察消失：单机程序崩溃即整体崩溃；分布式系统中一个节点崩溃，其余节点只能通过超时去"猜测"，而超时无法区分"对方宕机"与"网络慢"（见 kp-005、kp-006）。

正因如此，分布式设计的大量篇幅都花在回答同一类问题上：在没有可靠的全局信息时，如何让系统仍然安全（不出错）且尽量活着（不出局）。

图示

   客户端
     │ 请求
 ┌───┴───┐     网络（可能丢/慢/乱序/重复）
 │ 节点A │◄──────────────►│ 节点B │
 │ 独立  │    消息传递     │ 独立  │
 │故障域 │                │故障域 │
 └───────┘                └───┬───┘
                              │ A 挂了？B 无从立刻得知，
                              │ 只能靠超时猜测

直观类比

分布式系统像一群只能靠对讲机协作的人：对讲机会没电、会串台、会延迟；没有一个人能看到全局；喊话没回音时，分不清对方是没听见还是故意不理。所有协作协议都要在这种条件下仍然不做出错误决定。

实例或案例

DNS：全球最古老、最成功的分布式系统之一，层级缓存 + 最终一致性。
Kubernetes 集群：控制面（etcd，见 kp-020）+ 数千个工作节点，靠声明式状态收敛协作。
微服务集群：几十个服务跨几百个实例协作，每个服务都是潜在故障点。

常见误区

误区一："分布式 = 多台物理机"。不对：同一台机器上的多个进程（无共享内存）同样构成分布式系统，核心特征是独立故障域 + 消息传递，而非物理位置。
误区二："加机器就能解决性能问题"。协调成本（通信、锁、共识）随节点数增长，Amdahl 定律限制了可扩展性上限（见 kp-002）。
误区三："分布式系统只是单机系统的放大版"。部分失效与不确定时序是质的差异，不是量的差异。

与其他知识点的关系

kp-002：分布式系统用什么指标衡量"做对了"。
kp-005：部分失效的具体分类，一切容错设计的起点。
kp-012：CAP 定理把"不可靠网络 + 一致性/可用性"的矛盾形式化。

自测题

为什么说"同一台机器上的两个进程"也可以是分布式系统？

答：因为它们没有共享内存、通过消息（管道/socket）通信、拥有独立故障域，满足了分布式系统的本质特征，与物理位置无关。

部分失效为什么比整体失效更难处理？

答：整体失效时所有组件状态一致地"死了"；部分失效时存活节点面对的是不确定的失效视图（对方是慢了还是死了？），任何基于"对方状态"的决策都可能错。

举出一个你每天在用、却很少意识到是分布式系统的设施。

答：如 DNS——层级部署、多副本、缓存、最终一致，全球范围内跨机构协作。