大家好，我是Tony Bai。
欢迎来到《分布式系统：原理、哲学与实战》微专栏的第二讲。
在上一讲中，我们告别了秩序井然的单体城堡，决定踏入广阔的分布式联邦。但在正式探索之前，我们必须回答一个根本问题：我们所说的“分布式系统”，究竟是什么？
计算机科学大师 Leslie Lamport 曾给出一个充满哲学意味的调侃式定义：
“一个分布式系统就是，其中一台你甚至都不知道存在的计算机的故障，都可能导致你自己的计算机无法使用。”
这个定义精准地抓住了分布式系统的核心痛点——无处不在、且常常出人意料的局部故障。但作为工程师，我们需要一个更具建设性的定义来指导我们的设计。一个更经典的工程定义是这样的：
“一个分布式系统是若干独立计算机的集合，但对于这些计算机的用户来说，这个系统就像一台计算机一样。”
这个定义看似简单，却蕴含了分布式系统的两大核心矛盾，也直接引出了我们必须面对的“系统模型”——一个清晰的、公认的“环境设定”。它是我们从纷繁复杂的现实中提炼出的、用于指导工程设计的核心假设与约束。它帮助我们摒除无关的细节，聚焦于那些对系统成败至关重要的因素，并为我们后续所有的讨论提供一个共同的语境和坚实的基础。
让我们来仔细剖析这个定义：
“若干独立计算机的集合”: 这句话的潜台词是，这些计算机是自治的、异构的、会独立发生故障的。这一残酷的现实，迫使我们必须建立一个**节点模型 (Node Model)**，去系统性地思考节点会如何“死亡”或“犯错”。
“就像一台计算机一样”: 这是我们的终极目标——对用户透明。为了实现这个幻象，这些独立的计算机必须通过网络互相通信、协调。但网络本身是不可靠的，这就迫使我们必须建立一个通信模型 (Communication Model)。更进一步，为了有效协调，节点间又必须对事件的顺序达成某种一致，但在一个没有全局时钟的世界里，这就迫使我们必须建立一个时钟模型 (Timing Model)。
分布式系统的“定义”本身，就为我们推开了通往“系统模型”的三扇大门。今天，我们就将逐一深入这三个模型，为我们所处的这个现实世界，画一张精准的战场地图。
节点模型 (Node Model)：为“敌人”画像
我们已经知道，在现实世界中，节点必然会失效。但“失效”这个词过于笼统。一个节点的“死亡”方式，千差万别，其“险恶”程度也天差地别。为了精确地设计我们的容错系统，我们必须先为可能遇到的“敌人”——也就是故障——进行清晰地画像。
