biji/fenbushi.tex

\documentclass[a4paper,12pt]{report}
\usepackage[utf8]{inputenc}
\usepackage[UTF8]{ctex}
\usepackage{fancybox}
%\setmainfont{Noto Serif CJK SC}
%\setmainfont{FangSong}
\setmainfont{SimSun}
%\fontsize{16pt}


% Title Page
\title{学习笔记}
\author{行走的芦苇}


\begin{document}
\maketitle

\begin{abstract}
\end{abstract}
\chapter{分布式系统特征}
\section{简介}

分布式系统是其组件分布在连网的计算机上，组件之间通过传递消息进行通信和动作协调的系统，重要特征：组件的并发性、缺乏全局时钟、组件故障的独立性。构造分布式系统的挑战是处理其组件的异构性、开放性（允许增加或替换组件）、安全性、可伸缩性（用户的负载或数量增加时能正常运行的能力）、故障处理、组件的并发性、透明性和提供服务质量的问题。\par
构造和使用分布式系统的主要动力来源于对共享资源的期望\par
\marginpar{分布式系统与云计算的区别：云计算主要侧重资源的使用方式，包括硬件资源、软件资源，分布式系统是云计算的基础，包括底层物理设施，分布式文件系统，分布式存储系统；云计算是基于虚拟化，而分布式不同；接入模式不同}
复杂事件处理：Complex Event Processing\par
感兴趣数据项在分布式系统中称为事件

防火墙的作用是保护企业内部网，防止未授权的消息进出网络，通过过滤到达消息和外发消息来实现。可以在源和目的地进行过滤。

互联网服务提供商（Internet service Provider,ISP)是给个体用户和小型

云被定义成一组基于互联网的应用，并且足以满足大多数用户需求的存储和计算服务的集合，这使得用户能大部分或全部免除本地数据存储和应用软件的使用。网格计算也被看成是一种云计算，可以看成是云计算更通用模式的先驱，侧重于科学计算。\par
\textbf{服务}表示计算机系统中管理相关资源并提供功能给用户和应用的一个单独的部分；客户与服务器之间的完整交互，即从客户发送一个请求到它接收到服务器的应答，称为一个\textbf{远程调用}。在面向对象语言实现的分布式系统，资源被封装成对象，并由客户访问，这时，称一个客户对象调用了一个服务对象上的方法。客户与服务器仅仅是针对一个请求中扮演的角色而言，客户是主动的，服务器是被动的；服务器是持续运行的，而客户所持续的时间只是客户所属的那部分应用程序持续的时间。\par
\subsection{挑战}
\subsubsection{异构性}
\begin{itemize}
 \item 网络
 \item 计算机硬件
 \item 操作系统
 \item 编程语言
 \item 由不同开发者完成的软件实现
\end{itemize}
\textbf{中间件}是指一个软件层，它提供了编程抽象，同时屏蔽了底层网络、硬件、操作系统和编程语言的差异性。除了解决异构性的问题外，中间件为服务器和分布式应用的程序员提供了一致的计算模型，这些模型包括远程对象调用、远程事件通知、远程SQL访问和分布式事务处理。\textbf{移动代码}是指能从一台计算机发送到另一台计算机，并在目的计算机上运行的代码，Java applet是一个例子。\par
\subsubsection{开放性}
计算机系统的开放性是决定系统能否以不同的方式被扩展和重新实现的特征，分布式系统的开放性取决于新的共享服务能被增加和供多种客户程序使用的程度。除非软件开发者能获得系统组件的关键软件接口的规约和文档，否则无法实现开放性。开放的分布式系统主要强调可扩展性，从硬件层上，通过在网络上增加计算机实现硬件层次上扩展；通过引入新的服务、重新实现旧的服务实现在软件层次上的扩展，最终使用应用程序共享资源。

开放的分布式系统的特征总结如下：
\begin{itemize}
 \item 发布系统的关键接口是开放系统的特征
 \item 开放的分布式系统是基于一致的通信机制和发布接口访问共享资源的
 \item 开放的分布式系统能用不同销售商提供的异构硬件和软件构造。
\end{itemize}
\subsubsection{安全性}
信息资源的安全性包括三部分：机密性（防止泄露给未授权的个人）、完整性（防止被改变或被破坏）、可用性（防止对访问资源的手段的干扰）。
\subsubsection{可伸缩性}
分布式系统可在不同规模下有效且高效地运转。如果资源数量和用户数量激增，系统仍能保持其有效性，那么该系统就称为可伸缩的。

主要面临的挑战：控制物理资源的开销；控制性能损失；防止软件资源用尽；避免性能瓶颈。
\subsubsection{故障处理}
处理故障的技术：检测故障，掩盖故障，容错，故障恢复，冗余。

系统的可用性性是对系统可用时间的比例的一个度量指标。
\subsubsection{并发性}
在分布式系统中，代表共享对象的任何一个对象必须负责确保它在并发环境中操作正确，这不仅适用于服务器，也适用于应用中的对象。为了使对象在并发环境能安全使用，它的操作必须在数据保持一致的基础上同步。
\subsubsection{透明性}
透明性被定义成对用户和应用程序屏蔽分布式系统的组件的分离性，使系统被认为是一个整体，而不是独立组件的组合。透明性的含义对系统软件的设计有重大影响。\begin{itemize}
 \item 访问透明性：用相同的操作访问本地资源和远程资源
 \item 位置透明性：不需要知道资源的物理或网络位置
 \item 并发透明性：几个进程能并发地使用共享资源进行操作且互不干扰
 \item 复制透明性：使用资源的多个实例提升可靠性和性能，而用户和应用程序员无须知道副本的相关信息。
 \item 故障透明性：屏蔽错误，不论是硬件组件故障还是软件组件故障，用户和应用程序都能够完成它们的任务
 \item 移动透明性：资源和客户能够在系统内移动而不会影响用户或程序的操作
 \item 性能透明性：当负载变化时，系统能被重新配置以提高性能
 \item 伸缩透明性：系统和应用能够进行扩展而不改变系统结构或应用算法。
\end{itemize}
\subsubsection{服务质量}
系统的非功能特性，即影响客户和用户体验的服务质量是可靠性、安全性和性能。满足变化的系统配置和资源可用性的适应性已被公认为服务质量的一个重要方面。可靠性和安全性问题是设计大多数计算机系统时的关键，服务质量的性能方面源于及时性和计算吞吐量。


\chapter{系统模型}
\section{简介}
每类模型试图对分布式系统设计的一个相关方面给出抽象、简化但一致的描述。物理模型从计算机及其互联的网络方面考虑系统的硬件组成；体系结构模型从系统的计算元素执行的计算和通信任务方面来描述系统；基础模型抽象的观点描述分布式系统的某个方面，如交互模型，它考虑在系统元素之间通信的结构与顺序，故障模型考虑一个系统可能不能正确操作的方式，安全模型考虑如何保护系统使其不受到正确操作的干扰或不被窃取数据。

分布式系统的困难和威胁主要包括：
\begin{itemize}
 \item 使用模型的多样性
 \item 系统环境的多样性
 \item 内部问题，包括非同步的时钟、冲突的数据更新、多种涉及系统单个组件的软硬件故障模式
 \item 外部威胁：包括对数据完整性、保密性的攻击以及服务拒绝攻击
\end{itemize}
\section{物理模型}
物理模型是从计算机和所用的网络技术的特定细节中抽象出来的分布式系统底层硬件元素的表示
\section{体系结构模型}
一个系统的体系结构是用独立指定的组件以及这些组件之间的关系来表示的结构。整体目标是确保结构满足现在和将来可能的需求。主要关心的是系统的可靠性、可管理性、适应性和性价比。
\subsection{体系结构元素}
分布式系统的基础构建块，有必要考虑下面四个关键问题：
\begin{itemize}
 \item 在分布式系统中，通信的实体是什么
 \item 它们如何通信，特别是使用什么通信范式
 \item 它们在整个体系结构中扮演什么角色，承担什么责任
 \item 它们怎样被映射到物理分布式基础设施上
\end{itemize}
\textbf{通信实体}，从面向系统的角度看，包括进程和结点。面向问题，包括：对象，在分布式面向对象的方法中，一个计算由若干交互的对象组成，这些对象代表分解给定问题领域的自然单元；组件：类似于对象，也通过接口访问，关键区别在于组件不仅指定其接口而且给出关于其他组件/接口的假设，其他组件/接口是组件完成它的功能必须有的；web服务：web服务与对象和组件相关，也是采用基于行为封装和通过接口访问的方法，但通过利用web标准表示和发现服务，web服务本质上被集成到万维网中。

\textbf{通信范型}主要包括三种：进程间通信、远程调用、间接通信。进程间通信指的是用于分布式系统进程之间通信的相对底层的支持，包括消息传递原语、直接访问由互联网协议提供的API和对多播通信的支持。远程调用代表分布式系统中最见的通信范型，覆盖一系列分布式系统中通信实体之间基于双向交换的技术，包括调用远程操作、过程或方法。请求--应答协议用于支持客户--服务器计算。\par
远程过程调用（Remote Procedure Call,RPC)，在RPC中，远程计算机上进程中的过程能被调用，好像它们是在本地地址空间中的过程一样。\par
远程方法调用（Remove Method Invocation,RMI）应用于分布式对象环境，一个发起调用的对象能调用一个远程对象中的方法。\par
间接通信包括：组通信，是支持一对多通信的多方通信范型；发布--订阅系统，共享同一个关键的特征，即提供一个中间服务，有效确保由生产者生成的信息被路由到需要这个信息的消息者；消息队列，提供了点对点服务，生产者进程能发送消息到一个指定的队列，消息者进程能从队列中接收消息，队列临产者和消费者的中介；元组空间：进程能把任意的结构化数据项（元组）放在一个持久元组空间，其他进程可以指定感兴趣模式，从而可以在元组空间读或者删除元组；分布式共享内存：提供一种抽象，用于支持在不共享内存的进程之间共享数据。


\begin{tabular}{|c|c|c|c|c|}\hline
\multicolumn{3}{|c}{通信实体}\multicolumn{3}{|c|}{通信范型}\\\hline
面向系统的实体 & 面向问题的实体 & 进程间通信 & 远程调用 & 间接通信\\
    结点     & 对象         &  消息传递  & 请求-应答 &组通信\\
    进程     & 组件         & 套接字     &RPC   &发布-订阅\\
            &  web服务    &多播         &RMI   &消息队列\\
            &           &               & &元组空间\\
            &&&&DSM\\\hline
\end{tabular}
\textbf{角色与责任}：\texttt{客户-服务器}是讨论分布式系统最常引用的体系结构；\texttt{对待体系结构}作为对等方进行协作交互，不区分客户和服务器或运行它们的计算机，促使对等系统发展的主要观点是一个服务的用户所拥有的网络和计算资源也能被投入使用以支持那个服务。\par
\textbf{放置}考虑的问题是诸如对象或服务这样的实体是怎样映射到底层的物理分布式基础设施上的，需要考虑实体间的通信模式、给定机器的可靠性和它们当前的负载、不同机器之间的通信质量等。主要关注以下放置策略：
\begin{itemize}
 \item 将服务映射到多个服务器
 \item 缓存，代理服务器的目的是通过减少广域网和web服务器的负载，提高服务的可用性和性能。
 \item 移动代码
 \item 移动代理，是一个程序，它从一台计算机移动到网络上另一台计算机，代表某人完成诸如信息搜集之类的任务，最后返回结果。
\end{itemize}
其他模式：代理模式是主要用于支持远程过程调用或远程方法调用的过程位置透明性。web服务中的业务代理(brokerage)支持互操作性的体系结构模式，由服务提供者、服务请求者与服务代理（提供与请求的服务一致的服务）三部分组成。反射(reflection)模式作为支持内省（系统的动态发现的特性）和从中调停（动态修改结构或行为的能力）的手段而被持续地使用。在一个反射系统中，标准的服务接口在基础层可供使用，但元层接口也可以提供对涉及服务实现的组件及组件参数的访问。\par
\subsection{相关的中间件解决方案}
中间件任务是为分布式系统的开发提供一个高层的编程抽象，并且，通过分层，对底层基础设施中的异构性提供抽象，从而提升互操作性和可移植性。除了编程抽象外，中间件也能够提供分布式系统的基础设施服务。分布式程序正确行为在很多层面上依赖检查、错误校正机制和安全手段。
\section{基础模型}
所有模型都共享的设计需求：实现进程及网络性能和可靠性特征，确保系统中资源的安全性。
\subsection{交互模型}
分布式算法定义了组成系统的每个进程所采取的步骤，包括它们之间的消息传递。\textbf{通信信道的性能}，延迟：从一个进程开始发送消息到另一个进程开始接收消息之间的间隔时间称为延迟；计算机网络带宽是在给定时间内网络能传递的信息总量；抖动是传递一系列消息所花费的时间的变化值；时钟漂移率(clock drift rate)指计算机时钟偏离绝对参考时钟的比率。\par
异步分布式系统对进程执行速度、消息传递延迟和时钟漂移率没有限制。
\subsection{故障模型}
故障模型定义了故障可能发生的方式，以便理解故障所产生的影响，包括遗漏故障、随机故障和时序故障。遗漏故障类错误指进程或通信通道不能完成它应该做的动作；在异步系统中，超时只能表明进程没有响应，它可能崩溃了，也可能是执行速度慢，或者消息还没有到达。随机故障用于描述可能出现的最坏的故障，此时可能发生任何类型的错误。时序故障发生在同步分布式系统中。
\subsection{安全模型}
通过保证进程和用于进程交互的通道的安全以及保护所封装的对象免遭未授权访问可实现分布式系统的安全。
\chapter{网络和网际互联}
计算机网络所基于的原理包括协议分层、包交换、路由以及数据流等，网际互连技术使得异构网络可以集成在一起。
\section{简介}
对网络的需求：
\begin{itemize}
 \item 性能，影响两个互连计算机间消息的传输速度两个参数，延迟和点到点的数据传输率。延迟是指执行发送操作之后和到达目标计算机之前的这段时间；数据传输率是指一旦传输过程开始，数据在网络上两台计算机间传输的速度。传输率主要由它的物理特征决定的，而延迟主要由软件开销、路由延迟和与负载有关有统计因素决定。过载是指在网络上传输的数据过多。
 \item 可伸缩性。为了适应互联网下一阶段的发展，技术人员正在对寻址和路由机制进行一些实质性的改变
 \item 可靠性。通信错误的检测和校正通常由应用级软件完成。
 \item 安全性。防火墙在网关上运行，所谓网关是企业内部网入口点处的计算机。
 \item 移动透明性
 \item 服务质量
 \item 组播
\end{itemize}
\textbf{网络这部分内容讲述的并不深，不再做过多的记录，只是把一些基本概念重述一下。}

自适应路由，网络两点间的通信的最佳路由会周期性的重新评估，评估时会考虑到当时的网络流量以及故障情况。路由算法包括两部分内容：一是决定每个数据包穿梭于网络时所应经过的路径；二是必须通过监控流量和检测配置变化或故障来动态地更新网络的知识。

路由器信息协议（Router Information Protocol）：通过发送自己路由表信息的概要和邻接结点相互交互网络信息。周期性地并且只要本地路由表发生改变，就将自己的路由表发给邻接的所有可访问的路由器；当从邻接路由器接收这样的表时，如果接收到的表中给出了到达一个新目的地的路由，或对于已有的一个目的地更好的路由，则用新的路由更新本地的路由。

向量-距离算法可以用多种方法改进。开销，也被称为度量，可以根据链路的实际带宽来计算；可以修改算法，以增加信息收敛的速度。

经验表明，当网络的负载超过了其能力的80\%，系统的吞吐量会因为数据包丢失而下降，除非控制高负载链路的使用。

UDP数据报被封装在一个IP数据包中，它具有一个包含源端口号和目的端口号的短的头部、一个长度域和一个校验和，它不提供舆保证；TCP建立了一个双向的通信通道，包含额外机制以保证可靠性：排序，TCP发送进程将流分割成数据片断序列，然后将之作为IP数据包发送，每个TCP都有一个序号，它在该片断的第一个字节给出流中的字节数；流控制，发送方管理不能使接收方或者中间结点过载，这通过片断确认机制完成，确认片断中的窗口大小域指定了在下一个确认之前允许发送方传送的数据量。
\chapter{进程间通信}
\textbf{特征}：\par
\textit{同步和异步}每个消息目的地与一个队列相关，发送进程将消息添加到远程队列中，接收进程从本地队列中移除消息。在同步形式的通信中，发送进程和接收进程之间在每一个消息上阻塞。在异步情况下，send操作是非阻塞的，只要消息被复制到本地缓冲区，发送进程就可以继续进行其他处理，消息的传递与发送进程并行进行。receive操作有阻塞型和非阻塞型两种形式。在不阻塞操作中，接收进程在发出recieve操作后可继续执行它的程序，该操作在后台提供一个缓冲区，但它必须通过轮循或中断独立接收缓冲区已满的通知。在多线程情况下，阻塞型recieve缺点较少。

\textit{消息目的地}可以通过名字使用服务，可以使用服务重定位，但不能迁移，迁移指在系统运行时移动服务所在的位置。

\textit{可靠性}：如果一个点对点消息服务在丢失了“合理”数量的数据包后，仍能保证发送消息，那么该服务就被称为可靠的。

\textit{排序}：有些应用要求消息要按发送的顺序发送。

UDP数据报通信的一些问题：
\begin{itemize}
 \item 消息大小，接收进程要指定固定大小的用于接收消息的字节数组。底层IP协议最大数据包为216字节。大多数情况下，消息大小被限制为8KB左右。
 \item 阻塞，支持阻塞和非阻塞
 \item 超时，选择适当的超时不容易
 \item 任意接收，recieve不指定消息的来源
\end{itemize}
UPD故障模型：
\begin{itemize}
 \item 遗漏故障：消息偶尔会丢失
 \item 排序，消息可能没有按顺序发送
\end{itemize}

\section{覆盖网络}
一个面向特定应用的虚拟网络能建立在已有网络上并为特定的应用进行优化，而不改变底层网络的特征。每个虚拟网络有它自己特定的寻址模式、协议和路由算法，它们被重新定义以满足特定类应用的需要。

覆盖网络(overlay network)是一个结点和虚拟链接组成的虚拟网络，它位于一个底层网络之上，提供一些独有的功能：
\begin{itemize}
 \item 满足一类应用需求的服务或一个特别高层的服务，如多媒体内容的分发；
 \tem 在一个给定的联网环境中的更有效的操作，如在一个自组织网络中的路由；
 \item 额外的特色，如组播或安全通信。
\end{itemize}
\chapter{远程调用}
请求-应答协议描述了一个基于消息传递的范型，该协议支持在客户/服务器计算中遇到的消息双向传输。请求-应答协议的故障模型包括：存在遗漏故障和没有保证消息按照其发送顺序进行传输，除此之外，该协议还会遇到进程故障问题。

实现基于TCP流的请求-应答协议的原因之一是期望避免实现多包协议，因为TCP流可以传输任意长度的参数和结果。如果应用不要求TCP提供的所有机制，那么更有效的方法是定制一个基于UDP实现的协议。

HTTP方法：每个用户请求指定使用服务器资源的方法和该资源的URL,应答则说明该请求的状态：\par
GET：请求在参数中给出的URL对应的资源。\par
HEAD:与GET相同，但不返回任何数据。\par
POST：指定资源的URL,该资源可处理在请求消息体中提供的数据。\par
PUT：要求请求中提供的数据在存储时以指定的URL所标识的资源，要么作为现有资源修改，要么作为一种新资源。\par
OPTIONS：服务器提供给客户端能够应用到给定URL及其特定需求的方法列表\par
TRACE：服务器返回请求的消息，用于诊断目的。\par
DELETE:服务器删除给定URL所标识的资源。\par
PUT和DELETE操作是幂等操作。
\section{远程过程调用}
远程过程调用使分布式编程和传统编程相似，即实现了高级的分布透明性，底层RPC系统隐藏了分布式环境重要的部分，包括对参数和结果的编码和解码、消息传递以及保留过程调用要求的语义。

RPC调用语义：\textbf{或许调用语义}远程方法可能执行一次或者根本不执行，当没有任何容错措施时，就启用了或许语义。它可能遇到的故障模型：遗漏故障，如果调用或结果消息丢失；系统崩溃，由于包含远程的服务器出现故障。或许语义仅对那些可以接受偶然调用失败的应用是有用的。\textbf{至少一次调用语义}，调用者可能收到返回的结果，也可能收到一个异常。异常信息通知调用者没有接收到执行结果。至少一次调用语义可以通过重发请求消息来达到，它屏蔽了调用或结果消息的遗漏故障。其可能的故障模型为：由于包含远程对象的服务器故障而引起的系统崩溃；随机故障。如果服务器操作中的操作被设计成幂等操作，则至少一次是可以接受的。\textbf{至多一次调用语义}：调用者可以接收返回的结果，也可以接收一个异常。异常信息通知调用者没有收到执行结果。

\begin{tabular}{|c|c|c|c|}\hline
\multicolumn{3}{|c}{容错措施}&  \\\cline{1-3}
\end{tabular}

RPC致力于提供最少的位置透明性和访问透明性，隐藏（可能是远程的）过程的物理位置，也以同样的方式访问本地和远程的过程。中间件还能给RPC提供额外程度的透明性。

对于服务接口中的每个方法，访问服务的客户端包含一个存根过程(stub procedure)，该过程的行为对于客户端来说就像本地过程，负责把过程标识符和参数编码成一个请求消息，该消息通过它的通信模块发给服务器。当应答消息返回时，它将对结果进行解码。对于服务接口中的每个方法，服务器端包含分发器程序、服务器存根过程和服务过程。分发器过程根据请求消息中的过程标识符选择一个服务器存根过程，存根过程负责对请求消息中的参数解码，然后调用相应的服务过程，并把返回编码成应答消息。服务过程是服务接口的过程具体实现。

在远程方法引用（Remote Method Invocation)编程过程中，程序员能够在分布式系统软件开发中使用所有面向对象编程的功能，包括类、对象、继承的使用，以及相关面向对象的设计方法和相关的工具使用；在基于RMI系统中所有对象都有唯一的对象引用，对象引用可做为参数进行传递，因此RMI比RPC提供了更为丰富的参数传递语义。对象引用是第一类值（first-class value），因此它们可以赋给变量，也可以作为参数传递或者作为方法的结果返回。

对象的状态由它的实例变量值组成。分布式对象系统可以采用客户-服务器体系结构，也可以采用其他体系结构模型。如为了获得良好的容错性并提高性能，可以复制对象；为了改善性能和可能用，可以迁移对象。将客户和服务器对象分布在不同的进程中，可提高封装性。

不管是否在同一台计算机内，不同进程中的对象之间的方法调用都被认为是远程方法调用，在同一进程中的对象间的方法调用称为本地方法调用。我们将能够接收远程调用的对象称为远程对象。

远程对象引用：如果对象能访问远程对象的远程对象引用，那么它们就可以调用该远程对象上的方法。

远程接口：每个远程对象都有一个远程接口，由该接口指定哪些方法可以被远程调用。

远程对象引用是一个可以用于整个分布式系统的标识符，它指向某个唯一的远程对象。

RMI实现：
\begin{description}
 \item[通信模块] 两个相互协作的通信模块执行请求-应答协议，它们在客户和服务器之间传递请求和应答消息，两个通信模块一起负责提供一个指定的调用语义，例如至多一次；
 \item[远程引用模块]:负责在本地对象引用和远程对象引用模块之间进行翻译，并负责创建远程对象引用。每个模块有一个远程对象表，记录着该进程的本地对象调用与远程对象引用的对应关系。
 \item[伺服器]：是一个提供了远程对象主体的类的实例。由相应的骨架传递的远程请求最终是由伺服器来处理的。
 \item[代理]：作用是对调用者表现得像调用本地对象一样，从而使远程方法调用对客户透明。它不执行调用，而是将调用放在消息里传递给远程对象。代理中的每个方法会把一个目标对象的引用、它自身的methonID和它的参数编码进一个请求消息并发送到目标，然后等待应答消息。
 \item[分发器]：服务器对表示远程对象的每个类都有分发器和骨架。分发器接收来自通信模块的请求消息，并传递给请求消息，并使用methodID选择骨架中恰当的方法。
 \item[骨架]：远程对象类有一个骨架，用于实现远程接口中的方法 。这些方法与作为远程对象的主体的伺服器的方法极为不同。一个骨架方法将请求消息中的参数解码，并调用伺服器中相应方法。它等待完成，然后将结果与异常信息编码进应答消息，传递给发送方代理的方法。
 \item[绑定程序]：是一个单独远程对象，它维护一张表，表中包含从文本名字到远程对象引用的映射。
 \item[远程对象激活]：启动用于驻留远程对象的服务器进程被称为激活器，服务器应该在用户需要他们的任何时候启动。
\end{description}
\chapter{间接通信}
\begin{quotation}
 在计算机科学中，所有问题都可以通过某个层次上的间接方式来解决。
\end{quotation}
间接通信被定义为在分布式系统中实体通过中介者进行通信，没有发送者和接收者之间的直接耦合。使用中介者两个主要特性：
\begin{enumerate}
 \item 空间解耦：发送者不知道也不需要知道接收者的身份，反之亦然，参与者可以被替换、更新、复制或迁移。
 \item 时间解耦：发送者和接收者可以有独立的生命周期，即不需要同时存在才能通信。
\end{enumerate}
间接通信还常用于分布式系统事件的分发。主要缺点是增加中间层带来性能的开销。通信信道持久性对于实现时间解耦非常重要，即通信范型必须存储消息以便接收者准备好接收时传递消息。
\section{组通信}
组通信(group communication)提供了一种服务，在这种服务中，消息首先被发送到组中，然后该消息被传送到组中的所有成员中。发送者不知道接收者们的身份。组通信是对组播通信的一种抽象，可以通过IP组播或一个等价的覆盖网络实现，但增加了一些重要的特性，如管理组成员、检测故障、提供可靠性和排序保证。组播能有效利用带宽。

进程组是非常低级的，因为消息被传递到进程，并没有进一步提供对分发的支持；消息通常是非结构化的字节数组，不支持对复杂数据类型的编码。对象组提供更高级的组计算方法。一个对象组是一组对象的集合，这些对象并发地处理同一组调用，然后，各自返回其响应。

\emph{在组播中的可靠性和排序} 点对点通信中的可靠性：完整性(接收到的和发送的消息是一样的，没有消息传递两次)、有效性(任何要外发的消息最终都会被传递)。在可靠组播中，完整性保证消息至多被正确地传递一次，有效性保证消息最终会被传递。为了扩展语义以覆盖对多个接收者的消息传递，需要增加第三个特性，即协定(agreement)，如果消息被传递到一个进程，那么该消息被传递到本组中的所有进程。除了可靠性，组通信要求对传递到多个目的地的消息提供消息相对排序方面的额外保障。

组成员管理四个主要任务：提供组成员改变接口，故障检测，组成员改变时通知成员，执行组地址扩展。
\section{Publish-subscribe systems}
A publish-subscribe system is a sysem where publishers publish structured events to an event service and subscribers express interest in particular events through subscriptions which can b arbitrary patterns over the structured events.

Publish-subscribe systems have two main characteristics:
\begin{itemize}
 \item Heterogeneity: When event notifications are used as a means of communication, components in a distributed system that were not designed to interoperate can be made to work together.
 \item Aysnchronicity: Notifications are sent asynchronously by event-generating publishers to all the subscribers that have expressed an interest in them to prevent publishers needing to synchronize with subscibers-publishers and subscribers need to be decoupled.

\end{itemize}
a number of schemes defines and considered here in increasing order of sophistication:
\begin{itemize}
 \item Channel-based: In this approach,publishers publish events to named channels and subscribers then subscribe to one of these named channels to recieve all events sent to that channel.
 \item Topic-based: In this approach, we make the assumption that each notification is expressed in terms of a number of fields, with one field denoting the topic.
 \item Content-based approaches are a generalization of topic-based approaches allowing the expression of subscriptions over a range of fields in an event notification.
 \item type-based: These approaches are intrinsically linked with object-based approaches where objects have a specified type.
\end{itemize}

In gegeral, patterns can be logical,temporal or spatial.
\subsection{Implementation issues}
the task of a publish-subscribe system is clear:to ensure that events are deliverd efficiently to all subscribers that have filters defined that match that event. Added to this, there may be additional requirements in terms of security,scalability,failure handling,concurrency and quality of service.

In peer-to-peer approach,there is no distinction between publishers,subscribers and brokers; all nodes act as brokers, cooperatively implementing the required event routing functionlity.

The difference is that whereas message-passing systems have implicit queues associated with senders and receivers, message queuing system have explicit queues that are third-party entities, separate from the sender and receiver. It is this key difference that makes message queues an indirect communication paradigm whth crucial properities of space and time uncoupling.

The key implementation issue for message queuing systems is the choice between centralized and distributed implementations of the concept.


















\chapter{docker}
Singularity was created to run complex applications on HPC clusters in a \strong{simple, portable, and reproducible way}.


\chapter{基本概念}

\begin{itemize}
 \item 统一资源定位器：Uniform Resource Lockor,URL
 \item 统一资源定位符：Uniform Resource Indentifier,URI
\end{itemize}

\chapter{问题}

\begin{itemize}
 \item 联网的计算机如何做到时间同步
 \item
\end{itemize}

\end{document}