分布式系统概论

为什么需要分布式

根据摩尔定律，计算机的CPU性能每18个月就会提升一倍，但由晶体管设计性能在已经达到物理上的极限，随着人人们对互联网的需求日益提升，这种性能的瓶颈越来越明显。

巴菲特有个关于投资的名言，就是“不要把鸡蛋放在一个篮子里”。对于系统而言也是如此。厂商的机子不可能永远保证永远不坏，我们也无法保证黑客不会来对我们的系统搞基，最为关键的是，我们自己无法保证自己的程序不会出bug。所以问题无法避免，错误也不可避免。我们只能鸡蛋分散到不同的篮子里，来减轻一锅端的风险。

由计算机组成的网络无处不在，现如今我们的日常生活已经被各种不同类型的网络包围，如电话网络、企业网络、家庭网络以及各种类型的局域网，共同构成了我们称之为Internet的网络。因此，我们可以断言Internet是由各种不同类型、不同地区、不同领域的网络构成的互联网。我们可以发现，互联网并没有集中式的控制中心，而是由大量分离且互联的节点组成的。这正是一个分散式的模型。我们可以把这个概念类比到即将讲解的分布式概念上。

分布式概念是在网络这个大前提下诞生的。传统的计算是集中式的计算，使用计算能力强大的服务器处理大量的计算任务，但这种超级计算机的建造和维护成本极高，且明显存在很大的瓶颈。与之相对，如果一套系统可以将需要海量计算能力才能处理的问题拆分成许多小块，然后将这些小块分配给同一套系统中不同的计算节点进行处理，最后如有必要将分开计算的结果合并得到最终结果，那么就将这种系统称为分布式系统。

分布式系统的趋势

分布式系统正在经历巨大的变化，这可追溯到一系列有影响力的趋势：

出现了泛在联网技术；
出现了无处不在计算，它伴随着分布式系统中支持用户移动性的意愿；
对多媒体设备的需求增加；
把分布式系统作为一个设施。

泛在联网和现代互联网

现代互联网是一个巨大的由多种类型计算机网络互连的集合，网络的类型一直在增加，现在包括多种多样的无线通信技术，如Wii、WiMAX、蓝牙（参见第3章）和第三代移动电话网络。最终结果是联网已成为一个泛在的资源，设备可以在任何时间、任何地方被连接（如果愿意）。

互联网也是一个超大的分布式系统。它使得世界各地的用户都能利用诸如万维网、电子邮件和文件传送等服务。（有时，Web被不正确地等同于互联网。）服务集是开放的，它能够通过服务器计算机和新的服务的增加而被扩展。

移动和无处不在计算

设备小型化和无线网络方面的技术进步已经逐步使得小型和便携式计算设备集成到分布式系统中。这些设备包括：

笔记本电脑。
手持设备，包括移动电话、智能电话、GPS设备、传呼机、个人数字助理（PDA）、摄像机和数码相机
可穿戴设备，如具有类似PDA功能的智能手表。
嵌入在家电（如洗衣机、高保真音响系统、汽车和冰箱）中的设备。

分布式多媒体系统

另一个重要的趋势是在分布式系统中支持多媒体服务的需求。多媒体支持可以定义为以集成的方式支持多种媒体类型的能力。人们可以期望分布式多媒体系统支持离散类型媒体（如图片或正文消息）的存储、传输和展示。分布式多媒体系统应该能对连续类型媒体（如音频和视频）完成相同的功能，即它应该能存储和定位音频或视频文件，并通过网络传输它们（可能需要以实时的方式，因为流来自摄像机），从而能向用户展示多种媒体类型，以及在一组用户中共享多种类型的媒体。

把分布式计算作为一个公共设施

随着分布式系统基础设施的不断成熟，不少公司在推广这样的观点：把分布式资源看成一个商品或公共设施，把分布式资源和其他公用设施（例如水或电）进行类比。采用这个模型，资源通过合适的服务提供者提供，能被最终用户有效地租赁而不是拥有。这种模型可以应用到物理资源和更多的逻辑服务上。

联网的计算机可用诸如存储和处理这样的物理资源，从而无须自己拥有这样的资源。从一个维度看，用户可以为其文件存储（例如，照片、音乐或视频等多媒体数据的存储）需求和/或文件备份需求选择一个远程存储设施。类似地，利用这个方法，用户能租用一个或多个计算结点，从而满足他们的基本计算需求或者完成分布式计算。从另一个维度看，用户现在能用像Amazon和Google之类的公司提供的服务访问复杂的数据中心（网络化的设施，为用户或机构提供对拥有大量数据的数据仓库的访问）或计算基础设施。操作系统虚拟化是该方法关键的使能技术，它意味着实际上可以通过一个虚拟的而不是物理的结点为用户提供服务。这从资源管理角度给服务提供者提供了更大的灵活性。
用这种方法，软件服务也能跨全球互联网使用。确实，许多公司现在提供一整套服务用于租赁，包括诸如电子邮件和分布式日历之类的服务。例如，Google将其旗下的一系列业务服务捆绑成Google Apps[www.google.com I]。软件服务所遵循的标准，例如Web服务提供的标准，使得这类开发成为可能。

分布式系统会面临哪里挑战

毫无疑问，分布式系统对于集中式系统而言，在实现上会更加复杂。分布式系统将会是更难理解、设计、构建和管理的，同时意味着应用程序的根源问题更难发现。

设计分布式系统时，经常需要考虑如下的挑战：

异构性：分布式系统由于基于不同的网络、操作系统、计算机硬件和编程语言来构造，必须要考虑一种通用的网络通信协议来屏蔽异构系统之间的差异。一般交由中间件来处理这些差异。
缺乏全球时钟：在程序需要协作时，它们通过交换消息来协调它们的动作。紧密的协调经常依赖于对程序动作发生时间的共识，但是，实际上网络上计算机同步时钟的准确性受到极大的限制，即没有一个正确时间的全局概念。这是通过网络发送消息作为唯一的通信方式这一事实带来的直接结果。
一致性：数据被分散或者复制到不同的机器上，如何保证各台主机之间的数据的一致性将成为一个难点。
故障的独立性：任何计算机都有可能故障，且各种故障不尽相同。他们之间出现故障的时机也是相互独立的。一般分布式系统要设计成被允许出现部分故障而不影响整个系统的正常使用。
并发：分布式系统的目的，是为了更好的共享资源。那么系统中的每个资源都必须被设计成在并发环境中是安全的。
透明性：分布式系统中任何组件的故障、或者主机的升级、迁移对于用户来说都是透明的，不可见的。
开放性：分布式系统由不同的程序员来编写不同的组件，组件最终要集成成为一个系统，那么组件所发布的接口必须遵守一定的规范且能够被互相理解。
安全性：加密用于给共享资源提供适当的保护，在网络上所有传递的敏感信息，都需要进行加密。拒绝服务攻击仍然是一个有待解决的问题。
可扩展性：系统要设计成随着业务量的增加，相应的系统也必须要能扩展来提供对应的服务。

分布式系统构成

下面从三个方面论述分布式系统的构成：物理模型，体系结构模型，基础模型

物理模型

基线物理模型：分布式系统被定义成其位于联网计算机上的硬件或软件组件仅通过消息传递进行通信和协调动作的系统。这引出分布式系统的最小物理模型，最小物理模型是一组可扩展的计算机结点，这些结点通过计算机网络相互连接进行所需的消息传递。在这个基线模型之上，我们能有效地识别出三代分布式系统。
早期的分布式系统：这样的系统出现在20世纪70年代晚期和80年代早期，随着局域网技术如以太网的出现而出现。这些系统一般由通过局域网互联的10~100个结点组成，它们与互联网的连接有限并支持少量的服务（如共享的本地打印机和文件服务器以及电子邮件和互联网上的文件传输）。单个的系统大部分是同构的，开放性不是主要的问题。服务质量提供环很少，是围绕这样的早期系统开展的很多研究中的一个焦点。
互联网规模的分布式系统：在这个基础上，20世纪90年代更大规模的分布式系统开始出现，以适应当时互联网惊人的发展（例如，Google搜索引擎在1996年第一次发布）。即一个可扩展的结点集合，这些结点通过一个网络的网络（互联网）相互连接。这样的系统利用了互联网提供的基础设施从而变成真正的全球化。它们包含大量的结点并且为全球化组织提供分布式系统服务，也跨组织提供分布式系统服务。在这样的系统中，从网络、计算机体系结构、操作系统、所采用的语言和所涉及的开发团队方面来说，异构性是很突出的。这导致开放标准和相关的中间件技术（如CORBA和最近的Web服务等）的重要性不断增加。在这样的全球化系统中，采用了额外的服务来提供端到端的服务质量特性。
当代的分布式系统：在上述系统中，结点通常是台式机，因此是相对静态的（即在一段时间里停留在一个物理位置）、分立的（没有嵌人到其他物理实体内）和自治的（就物理基础设施而言，很大程度上独立于其他计算机）。 ·移动计算的出现导致这样的物理模型，在这种模型中，像笔记本电脑或智能手机这样的结点可以从一个位置移动到另一个位置，它还导致了对诸如服务发现这样的新增功能的需要和对自发互操作的支持。 ·无处不在计算的出现导致了体系结构从分立结点磁转向计算机被嵌入到日常物品和周围环境中（例如，嵌入在洗衣机中或更一般地嵌入在智能家庭设备中）。 ·云计算特别是集群体系结构的出现导致了从自治结点完成给定任务转向一组结点一起提供一个给定的服务（例如，由Google提供的搜索服务）。

体系结构模型

为了理解一个分布式系统的基础构建块，有必要考虑下面四个关键问题：在分布式系统中进行通信的实体是什么？
它们如何通信，特别是使用什么通信范型？
它们在整个体系结构中扮演什么（可能改变的）角色，承担什么责任？
它们怎样被映射到物理分布式基础设施上（它们被放置在哪里）？

通信实体

对象：对象已被引人以便在分布式系统中使用面向对象的方法（包括面向对象的设计和面向对象的编程语言）。在分布式面向对象的方法中，一个计算由若干交互的对象组成，这些对象代表分解给定问题领域的自然单元。对象通过接口被访问，用一个相关的接口定义语言（IDL）提供定义在一个对象上的方法的规约。分布式对象已经成为分布式系统研究的一个主要领域。

组件：因为对象的引入，许多重要的问题已被认为与分布式对象有关，组件技术的出现及使用是对这些弱点的一个直接响应。组件类似于对象，因为它们为构造分布式系统提供面向问题的抽象，也是通过接口被访问。关键的区别在于组件不仅指定其（提供的）接口而且给出关于其他组件/接口的假设，其他组件/接口是组件完成它的功能必须有的。换句话说，组件使得所有依赖显式化，为系统的构造提供一个更完整的合约。这个合约化的方法鼓励和促进第三方开发组件，也通过去除隐含的依赖提升了一个更纯粹的组合化方法来构造分布式系统。基于组件的中间件经常对关键领域如部署和服务器方编程支持提供额外的支持[Heineman and Councill2001]。

Web服务：Web服务代表开发分布式系统的第三种重要的范型[Alonso et al.2004]。Web服务与对象和组件紧密相关，也是采取基于行为封装和通过接口访问的方法。但是，相比而言，通过利用Web标准表示和发现服务，Web服务本质上是被集成到万维网（即W3C）的。W3C（World Wide Web）联盟把Web服务定义成：

一个软件应用，通过URI被辨识，它的接口和绑定能作为XML制品被定义、描述和发现。一个Web服务通过在基于互联网的协议上利用基于XML的消息交换支持与其他软件代理的直接交互。

通信范型

我们现在转向在分布式系统中实体如何通信，考虑三种通信范型：

进程间通信

指的是用于分布式系统进程之间通信的相对底层的支持，包括消息传递原语、直接访问由互联网协议提供的API（套接字编程）和对多播通信的支持。第4章将详细讨论这样的服务。

远程调用

代表分布式系统中最常见的通信范型，覆盖一系列分布式系统中通信实体之间基于双向交换的技术，包括调用远程操作、过程或方法。

请求一应答协议是一个有效的模式，它加在一个底层消息传递服务之上，用于支持客户-服务器计算。特别的，这样的协议通常涉及一对消息的交换，消息从客户到服务器，接着从服务器返回客户，第一个消息包含在服务器端执行的操作的编码，然后是保存相关参数的字节数组，第二个消息包含操作的结果，它也被编码成字节数组。这种范型相对原始，实际上仅被用于嵌入式系统，对嵌入式系统来说性能是至关重要的。这个方法也被用在5.2节描述的HTTP协议中。正如下面讨论的，大多数分布式系统将选择使用远程过程调用或者远程方法调用，但注意底层的请求-应答交换支持两种方法。
远程过程调用（Remotc Procedure Call，RPC）的概念，最初由Birmell和Nelson[1984]提出，代表了分布式计算中的一个主要突破。在RPC中，远程计算机上进程中的过程能被调用，好像它们是在本地地址空间中的过程一样。底层RPC系统隐藏了分布的重要方面，包括参数和结果的编码和解码、消息的传递和保持过程调用所要求的语义。这个方法直接而且得体地支持了客户一服务器计算，其中，服务器通过一个服务接口提供一套操作，当这些操作本地可用时客户直接调用这些操作。因此，RPC系统（在最低程度上）提供访问和位置透明性。
远程方法调用（Remote Method Invocation，RMI）非常类似于远程过程调用，但它应用于分布式对象的环境。用这种方法，一个发起调用的对象能调用一个远程对象中的方法。与RPC一样，底层的细节都对用户隐藏。不过，通过支持对象标识和在远程调用中传递对象标识符作为参数，RMI实现做得更多。它们也从与面向对象语言的紧密集成中获得更多的好处。

间接通信

间接通信的关键技术包括：

组通信：组通信涉及消息传递给若干接收者，因此是支持一对多通信的多方通信范型。组通信依赖组抽象，一个组在系统中用一个组标识符表示。接收方通过加入组，就能选择性接收发送到组的消息。发送者通过组标识符发送消息给组，因此，不需要知道消息的接收者。组通常也要维护组成员，具有处理组成员故障的机制。
发布一订阅系统：许多系统，例如金融贸易的例子，被归类于信息分发系统，其中，大量生产者（或发布者）为大量的消费者（或订阅者）发布他们感兴趣的信息项（事件）。采用前述的任一核心通信范型来实现这个需求是复杂且低效的，因此，出现了发布-订阅系统（有时也叫分布式基于事件的系统）用于满足此项重要需求[Muhlet al.2006]。发布-订阅系统共享同一个关键的特征，即提供一个中间服务，有效确保由生产者生成的信息被路由到需要这个信息的消费者。
消息队列：虽然发布一订阅系统提供一种一对多风格的通信，但消息队列提供了点对点服务，其中生产者进程能发送消息到一个指定的队列，消费者进程能从队列中接收消息，或被通知队列里有新消息到达。因此，队列是生产者和消费者进程的中介。
元组空间：元组空间提供了进一步的间接通信服务，并支持这样的模型一—进程能把任意的结构化数据项（称为元组）放到一个持久元组空间，其他进程可以指定感兴趣的模式，从而可以在元组空间读或者删除元组。因为元组空间是持久的，读操作者和写操作者不需要同时存在。这种风格的编程，也被称为生成通信，由Gelemter[1985]作为一种并行编程范型引人。已经开发了不少分布式实现，采用了客户-服务器-风格的实现或采用了更分散的对等方法。
分布式共享内存：分布式共享内存（Distributed Shared Memory，DSM）系统提供一种抽象，用于支持在不共享物理内存的进程之间共享数据。提供给程序员的是一套熟悉的读或写（共享）数据结构的抽象，就好像这些数据在程序员自己本地的地址空间一样，从而提供了高层的分布透明性。基本的基础设施必须确保以及时的方式提供副本，也必须处理与数据同步和一致性相关的问题。

角色和责任

在一个分布式系统中，进程，或者说，对象、组件、服务，包括Web服务（为简单起见，我们在本节中使用术语“进程”）相互交互完成一个有用的活动，例如支持一次聊天会话。在这样做的时候，进程扮演给定的角色，在建立所采用的整体体系结构时，这些角色是基本的。

客户-服务器：这是讨论分布式系统时最常引用的体系结构。它是历史上最重要的体系结构，现在仍被广泛地使用。进程扮演服务器和客户的角色。特别是，为了访问服务器管理的共享资源，客户进程可以与不同主机上的服务器进程交互。一台服务器也可以是其他服务器的客户。例如，Wcb服务器通常是管理存储 Web页面文件的本地文件服务器的客户。Web服务器和大多数其他互联网服务是DNS服务的客户，DNS服务用于将互联网域名翻译成网络地址。另一个与Web相关的例子是搜索引学，搜索引擎能让用户通过互联网查看Web页面上可用的信息汇总。这些信息汇总通过称为“Web抓取”的程序形成，该程序在搜索引擎站点以后台方式运行，利用HTTP请求访问互联网上的Web服务器。因此，搜索引擎既是服务器又是客户：它回答来自浏览器客户的查询，并且运行作为其他Web服务器客户的Web抓取程序。在这个例子中，服务器任务（对用户查询的回答）和Web抓取的任务（向其他Web服务器发送请求）是完全独立的，很少需要同步它们，它们可以并行运行。事实上，一个典型的搜索引擎正常情况下包含许多并发执行的线程，一些线程为它的客户服务，另一些线程运行Web抓取程序。

对等体系结构：在这种体系结构中，涉及一项任务或活动的所有进程扮演相同的角色，作为对等方进行协作交互，不区分客户和服务器或运行它们的计算机。在实践中，所有的参与进程运行相同的程序并且相互之间提供相同的接口集合。虽然客户-服务器模型为数据和其他资源的共享提供了一个直接和相对简单的方法，但客户-服务器模型的伸缩性比较差。将一个服务放在单个地址中意味着集中化地提供服务和管理，它的伸缩性不会超过提供服务的计算机的能力和该计算机所在网络连接的带宽。

放置

最后要考虑的问题是诸如对象或服务这样的实体是怎样映射到底层的物理分布式基础设施上的，物理分布式基础设施由大量的机器组成，这些机器通过一个任意复杂的网络互联。从决定分布式系统特性的角度而言，放置是关键的，这些特性大多数与性能相关，也包括其他特性如可靠性和安全性。

将服务映射到多个服务器：服务可实现成在一个单独主机上的几个服务器进程，在必要时进行交互以便为客户进程提供服务。服务器可以将服务所基于的对象集分区，然后将这些分区分布到各个服务器上；或者服务器可以在几个主机上维护复制的对象集。Web就是一个常见的将数据分区的例子，其中的每个Web服务器管理自己的资源集。用户可以利用浏览器访问任一个服务器上的资源。一个基于复制数据的服务是Sun网络信息服务（Network Information Service，NIS）。它使得LAN中的计算机能在用户登录时访问到相同的用户认证数据。每个NIS服务器有它自己的口令文件副本，该副本记录了用户登录名和加密的口令清单。

缓存：缓存用于存储最近使用的数据对象，这些被存储的数据对象比对象本身更靠近一个客户或特定的一组客户。当服务器接收一个新对象时，就将它存入缓存，必要的时候会替换缓存中已存在的对象。当客户进程需要一个对象时，缓存服务首先检查缓存，如果缓存中有最新的拷贝可用就提供缓存中的对象；如果缓存没有可用的对象，才去取一个最新的拷贝。每个客户都可以配置缓存或者将缓存放置在由几个客户共享的代理服务器上。缓存在实际工作中被广泛使用。Web浏览器维护一个缓存，它在客户本地的文件系统中存放最近访问的Web页面和其他Web资源，并在显示前用一个特殊的HTTP请求到原来的服务器上检查被缓存的页面是否是最新的。Web代理服务器为一个或多个地点的客户机提供共享的存放Web资源的缓存。代理服务器的目的是通过减少广域网和Web服务器的负载，提高服务的可用性和性能。代理服务器能承担其他角色，例如它们可以用于通过防火墙访问远程Web服务器。

移动代码：applet是一个众所周知的并被广泛使用的移动代码例子，即运行浏览器的用户选择了一个到applet的链接，applet的代码存储在Web服务器上，将applet的代码下载到浏览器并在浏览器端运行，在本地运行下载的代码的好处是能够提供良好的交互响应，因为它不受与网络通信相关的延迟或带宽变化的影响。

移动代理：移动代理是一个运行的程序（包括代码和数据），它从一台计算机移动到网络上的另一台计算机，代表某人完成诸如信息搜集之类的任务，最后返回结果。一个移动代理可能多次调用所访问地点的本地资源——例如，访问一个数据库条目。如果将这种体系结构与对某些资源进行远程调用的静态客户相比，那么后者可能会传输大量的数据，前者通过用本地调用替换远程调用而降低了通信开销和时间。

体系结构模式

分层

分层的概念是一个熟悉的概念，与抽象紧密相关。在分层方法中，一个复杂的系统被分成若干层，每层利用下层提供的服务。因此，一个给定的层提供一个软件抽象，更高的层不清楚实现细节，或不清楚在它下面的其他层。分层分层的概念是一个熟悉的概念，与抽象紧密相关。在分层方法中，一个复杂的系统被分成若干层，每层利用下层提供的服务。因此，一个给定的层提供一个软件抽象，更高的层不清楚实现细节，或不清楚在它下面的其他层。

就分布式系统而言，这等同于把服务垂直组织成服务层。一个分布式服务可由一个或多个服务器进程提供，这些进程相互交互，并与客户进程交互，维护服务中的资源在系统范围内的一致视图。例如，在互联网上基于网络时间协议（Network Time Protocol，NTP）可实现一个网络时间服务，其中，服务器进程运行在互联网的主机上，给任一发出请求的客户提供当前的时间，作为与服务器交互的结果，客户调整它们的当前时间。给定分布式系统的复杂性，这些服务组织成若干层经常是有帮助的。

层次化体系结构

层次化体系结构与分层体系结构是互补的。分层将服务垂直组织成抽象层，而层次化是一项组织给定层功能的技术，它把这个功能放在合适的服务器上，或者作为第二选择放在物理结点上。这个技术与图2-7中所示的应用和服务的组织最相关，但它也可以应用到一个分布式系统体系结构的所有层。我们先查看两层和三层体系结构概念。为了说明这些概念，考虑如下对一个给定应用的功能分解： ·表示逻辑，涉及处理用户交互和修改呈现给用户的应用视图； ·应用逻辑，涉及与应用相关的（也称为业务逻辑，虽然这个概念不仅仅限于业务应用）详细的应用特定处理； ·数据逻辑，涉及应用的持久存储，通常在一个数据库管理系统中。

瘦客户

瘦客户分布式计算的趋势是将复杂性从最终用户设备移向互联网服务。这点在向云计算发展的趋势中最明显，在上面讨论的层次化体系结构中也能看到。这个趋势导致了对瘦客户概念的兴趣，它使得能以很少的对客户设备的假设或需求，获得对复杂网络化服务的访问，这些服务可以通过云解决方案提供。更具体来说，术语瘦客户指的是一个软件层，在执行一个应用程序或访问远程计算机上的服务时，由该软件层提供一个基于窗口的本地用户界面。

其他经常出现的模式

·代理（proxy）模式是分布式系统中经常出现的模式，其主要用于支持远程过程调用或远程方法调用的位置透明性。用这种方法，一个代理在本地地址空间中被创建，用于代表远程对象。这个代理提供与远程对象一样的接口，程序员调用这个代理对象，因此无须了解交互的分布式特性。在RPC和RMI中，代理支持位置透明性的作用将在第5章做进一步的讨论。注意代理也被用于封装其他的功能（诸如复制或缓存的放置策略等）。

·Web服务中的业务代理（brokerage）的使用能被看成是一个在可能很复杂的分布式基础设施中支持互操作性的体系结构模式。特别地，这个模式是由服务提供商、服务请求者和服务代理（提供与请求的服务一致的服务）三部分组成。

·反射（reflection）模式在分布式系统中作为支持内省（系统的动态发现的特性）和从中调停（动态修改结构或行为的能力）的手段而被持续地使用。例如，Java的内省能力被用于RMI的实现中，提供通用的分发。在一个反射系统中，标准的服务接口在基础层可供使用，但元层接口也可以提供对涉及服务实现的组件及组件参数的访问。

中间件解决方案

中间件的顶层分类是根据通信实体和相关通信范型而确定的，遵循五个主要的体系结构模型：分布式对象、分布式组件、发布-订阅系统、消息队列和Web服务。

基础模型

通常，为了理解和推理系统行为的某些方面，一个基础模型应该仅包含我们要考虑的实质性成分。这样一个模型的目的是： ·显式地表示有关我们正在建模的系统的假设。 ·给定这些假设，就什么是可能的、什么是不可能的给出结论。结论以通用算法或要确保的特性的形式给出。特性成立的保证依赖于逻辑分析和（适当时候的）数学证明。

了解设计依赖什么、不依赖什么，我们就能从中获益。如果在一个特定系统中实现一个设计，这个设计能否运作，我们只需询问在那个系统中假设是否成立。通过清晰、显式地给出我们的假设，就能利用数学技巧证明系统的特征，这些特征对任何满足假设的系统都成立。最后，通过从细节（如硬件）中抽象系统的基本实体和特性，我们就能阐明对系统的理解。我们希望在我们的基本模型中提取的分布式系统情况能解决下列问题：

交互：计算在进程中发生，进程通过传递消息交互，并引发进程之间的通信（信息流）和协调（活动的同步和排序）。在分布式系统的分析和设计中，我们特别关注这些交互。交互模型必须反映通信带来的延迟，这些延迟的持续时间会比较长，交互模型必须反映独立进程相互配合的准确性受限于这些延迟，受限于在分布式系统中很难跨所有计算机维护同一时间概念。
故障：只要分布式系统运行的任一计算机上出现故障（包括软件故障）或连接它们的网络出现故障，分布式系统的正确操作就会受到威胁。我们的模型将对这些故障进行定义和分类。这为分析它们潜在效果以及设计能容忍每种类型故障的系统奠定了基础。
安全：分布式系统的模块特性和开放性将其暴露在外部代理和内部代理的攻击下。我们的安全模型对发生这种攻击的形式给出了定义并进行了分类，为分析对系统的威胁以及设计能抵御这些威胁的系统奠定了基础。

大多数程序员非常熟悉算法的概念—采取一系列步骤以执行期望的计算。简单的程序由算法控制，算法中的每一步都有严格的顺序。由算法决定程序的行为和程序变量的状态。这样的程序作为一个进程执行。由多个上面所说的进程组成的分布式系统是很复杂的。它们的行为和状态能用分布式算法描述一—分布式算法定义了组成系统的每个进程所采取的步骤，包括它们之间消息的传递。消息在进程之间传递以便在它们之间传递信息并协调它们的活动。

每个进程执行的速率和进程之间消息传递的时限通常是不能预测的。要描述分布式算法的所有状态也非常困难，因为它必须处理所涉及的一个或多个进程的故障或消息传递的故障。

进程交互完成了分布式系统中所有的活动。每个进程有它自己的状态，该状态由进程能访问和更新的数据集组成，包括程序中的变量。属于每个进程的状态完全是私有的一—也就是说，它不能被其他进程访问或更新。本节讨论分布式系统中影响进程交互的两个重要因素： ·通信性能经常是一个限制特性。

·不可能维护一个全局时间概念。

通信通道的性能

通信通道的性能在我们的模型中，通信通道在分布式系统中可用许多方法实现，例如，通过计算机网络上的流或简单消息传递来实现。计算机网络上的通信有下列与延迟（latency）、带宽（band-width）和抖动（jitter）有关的性能特征： ·从一个进程开始发送消息到另一个进程开始接收消息之间的间隔时间称为廷迟。延迟包括：一第一串比特通过网络传递到目的地所花费的时间。例如，通过卫星链接传递消息的延迟是无线电信号到达卫星并返回的时间。一访问网络的延迟，当网络负载很重时，延迟增长很快。例如，对以太网传送面言，发送站点要等待网络空闲。一操作系统通信服务在发送进程和接收进程上所花费的时间，这个时间会随操作系统当前的负载的变化而变化。 ·计算机网络的带宽是指在给定时间内网络能传递的信息总量。当大量通信通道使用同一个网络时，它们就不得不共享可用的带宽。 ·抖动是传递一系列消息所花费的时间的变化值。抖动与多媒体数据有关。例如，如果音频数据的连续采样在不同的时间间隔内播放，那么声音将严重失真。

计算机时钟和时序事件

分布式系统中的每台计算机有自已的内部时钟，本地进程用这个时钟获得当前时间值。因此，在不同计算机上运行的两个进程能将时间戳与它们的事件关联起来。但是，即使两个进程在同时读它们的时钟，它们各自的本地时钟也会提供不同的时间值。这是因为计算机时钟和绝对时间之间有偏移，更重要的是，它们的漂移率互不相同。术语时仲漾移率（clock drift rate）指的是计算机时钟偏离绝对参考时钟的比率。即使分布式系统中所有计算机的时钟在初始情况下都设置成相同的时间，它们的时钟最后也会相差巨大，除非进行校正。

有几种校正计算机时钟的时间的方法。例如，计算机可使用无线电接收器从全球定位系统（GPS）以大约1us的精度接收时间读数。但GPS接收器不能在建筑物内工作，同时，为每一台计算机增加GPS在费用上也不合理。相反，具有精确时间源（如GPS）的计算机可发送时序消息给网络中的其他计算机。在两个本地时钟时间之间进行协商当然会受消息延迟的影响。

交互模型的两个变体

交互模型的两个变体在分布式系统中，很难对进程执行、消息传递或时钟漂移所花的时间设置时间限制。两种截然相反的观点提供了一对简单模型：第一个模型对时间有严格的假设，第二个模型对时间没有假设。同步分布式系统：Hadzilacos和Toueg[1994]定义了一个同步分布式系统，它满足下列约束： ·进程执行每一步的时间有一个上限和下限。 ·通过通道传递的每个消息在一个已知的时间范围内接收到。 ·每个进程有一个本地时钟，它与实际时间的偏移率在一个已知的范围内。对于分布式系统，建议给出合适的关于进程执行时间、消息延迟和时钟漂移率的上界和下界是可能的。但是达到实际值并对所选值提供保证是比较困难的。除非能保证上界和下界的值，否则任何基于所选值的设计都不可靠。但是，按同步系统构造算法，可以对算法在实际分布式系统的行为提供一些想法。例如，在同步系统中，可以使用超时来检测进程的故障。同步分布式系统是能够被构造出来的。所要求的是进程用已知的资源需求完成任务，这些资源需求保证有足够的处理器周期和网络能力；还有要为进程提供漂移率在一定范围内的时钟。异步分布式系统：许多分布式系统，例如互联网，是非常有用的，但它们不具备同步系统的资格。

因此我们需要另一个模型。异步分布式系统是对下列因素没有限制的系统： ·进程执行速度——例如，进程的一步可能只花费亿万分之一秒，而进程的另一步要花费一个世纪的时间，也就是说，每一步能花费任意长的时间。 ·消息传递延迟一—例如，从进程A到进程B传递一个消息的时间可能快得可以忽略，也可能要花费几年时间。换句话说，消息可在任意长时间后接收到。 ·时钟漂移率——时钟漂移率可以是任意的。异步模型对执行的时间间隔没有任何假设。这正好与互联网一致，在互联网中，服务器或网络负载没有内在的约束，对像用FTP传输文件要花费多长时间也没有限制。有时电子邮件消息要花几天时间才能到达。下面的“Pepperland协定”部分说明在异步分布式系统中达成协定的困难性。即使有这些假设，有些设计问题也能得到解决。例如，虽然Web并不总能在一个合理的时间限制内提供特定的响应，但浏览器的设计可以做到让用户在等待时做其他事情。对异步分布式系统有效的任何解决方案对同步系统同样有效。实际的分布式系统经常是异步的，因为进程需要共享处理器，而通信通道需要共享网络。例如，如果有太多特性未知的进程共享一个处理器，那么任何一个进程的性能都不能保证。但是，有许多不能在异步系统中解决的设计问题，在使用时间的某些特征后就能解决。在最终期限之前传递多媒体数据流的每个元素就是这样一个问题。对这样的问题，可使用同步模型。

事件排序

在许多情况下，我们有兴趣知道一个进程中的一个事件（发送或接收一个消息）是发生在另一个进程中的另一个事件之前、之后或同时。尽管缺乏精确的时钟，但系统的执行仍能用事件和它们的顺序来描述。

因为在一个分布式系统中时钟不能精确同步，所以Lamport[1978]提出了逻辑时间的模型，为在分布式系统中运行于不同计算机上的进程的事件提供顺序。使用逻辑时间不需要求助于时钟就可以推断出消息的顺序。

故障模型

在分布式系统中，进程和通信通道都有可能出故障，即它们可能偏离被认为是正确或所期望的行为。故障模型定义了故障可能发生的方式，以便理解故障所产生的影响。Hadailacos和Toueg[1994]提供了一种分类法，用于区分进程故障和通信通道故障。这些故障将分别在下面的“遗漏故障”、“随机故障”和“时序故障”部分介绍。

遗漏故障

遗漏故障类错误指的是进程或通信通道不能完成它应该做的动作。进程遗漏故障：进程主要的遗漏故障是崩溃。当我们说进程崩溃了，意为进程停止了，将不再执于程序的任何步骤。能在故障面前存活的服务，如果假设该服务所依赖的服务能干净利落地崩溃，即进程仍能正确运行或者停止运行，那么它的设计能被简化。其他进程通过下列事实能检测到这种进程的溃：这个进程一再地不能对调用消息进行应答。然而，这种崩溃检测的方法依赖超时的使用，即进用一段固定时间等待某个事件的发生。在异步系统中，超时只能表明进程没有响应——它可能是崩贵了，也可能是执行速度慢，或者是消息还没有到达。如果其他进程能确切检测到进程已经崩溃，那么这个进程崩溃称为故降一停止。在同步系统中，如果确保消息已被传递，而其他进程又没有响应时，进程使用超时来检测，那么就会产生故障-停止行为。例如，对于进程p和g，如果设计q应答来自p的消息，而且进程p在按p本地时钟度量的一个最大时间范围内没有收到进程q的应答，那么进程p可以得出结论：进程g出现了故障。下面的“故障检测”和“面对通信故障时达成协定的不可能性”部分说明在异步系统中检测故障的困难以及在故障面前达成协定的困难。

通信遗漏故障：考虑通信原语 send和receive。进程p通过将消息m插入到它的外发消息缓冲区来执行send。通信通道将m传输到q的接收消息级冲区。进程q通过将m从它的接收消息缓冲区取走并完成传递来执行receive。通常由操作系统提供外发消息缓冲区和接收消息缓冲区。

如果通信通道不能将消息从p的外发消息缓冲区传递到q的接收消息缓冲区，那么它就产生了遗漏故障。这就是所谓的“丢失消息”，造成消息丢失的原因通常是在接收端或中间的网关上缺乏缓冲区空间，或因为网络传输错误（可由消息数据携带的校验和检测到）。Hadzilacos和Toueg[1994]把在发送进程和外发消息缓冲区之间的消息丢失称为发送遗漏故障；在接收消息缓冲区和接收进程之间的消息丢失称为接收遗漏故障；在两者之间的消息丢失称为通道遗漏故障。

时序故障

时序故障适用于同步分布式系统。在这样的系统中，对进程执行时间、消息传递时间和时钟源移率均有限制。

在异步分布式系统中，一个负载过重的服务器的响应时间可能很长，但我们不能说它有时序故障，因为它不提供任何保证。实时操作系统是以提供时序保证为目的而设计的，但这种系统在设计上很复杂的，会要求冗余的硬件。大多数通用的操作系统（如UNIX）不能满足实时约束。时序与有音频和视频通道的多媒体计算机的关系尤为密切。视频信息要求传输海量的数据。若要在传递视频信息时不出现时序故障，那么就要对操作系统和通信系统提出特殊的要求。

故障屏蔽

分布式系统中的每个组件通常是基于其他一组组件构造的。利用存在故障的组件构造可靠的服务是可能的。例如，保存有数据副本的多个服务器在其中一个服务器崩溃时能继续提供服务。了解组件的故障特征有利于在设计新服务时屏蔽它所依赖的组件的故障。一个服务通过隐藏故障或者将故障转换成一个更能接受的故障类型来屏蔽故障。对于后者，我们给出一个例子，校验和用于屏蔽故障屏蔽分布式系统中的每个组件通常是基于其他一组组件构造的。利用存在故障的组件构造可靠的服务是可能的。例如，保存有数据副本的多个服务器在其中一个服务器崩溃时能继续提供服务。了解组件的故障特征有利于在设计新服务时屏蔽它所依赖的组件的故障。一个服务通过隐藏故障或者将故障转换成一个更能接受的故障类型来屏蔽故障。对于后者，我们给出一个例子，校验和用于屏蔽

一对一通信的可靠性

虽然基本的通信通道可能出现前面描述的遗漏故障，但用它来构造一个能屏蔽某些故障的通信服务是可能的。术语可素通信可从下列有效性和完整性的角度来定义：有效性：外发消息缓冲区中的任何消息最终能传递到接收消息缓冲区。完整性：接收到的消息与发送的消息一致，没有消息被传递两次。对完整性的威胁来自两个方面： ·任何重发消息但不拒绝到达两次的消息的协议。要检测消息是否到达了两次，可以在协议中给消息附加序号。 ·心怀恶意的用户，他们可能插入伪造的消息、重放旧的消息或篡改消息。在面对这种攻击时为维护空整：班买面相应的安全措渐