分3大块
physical mode（只考虑物理连接方面的模型）；
architechture mode（主要是“计算”方面的体系结构模型，例如peer to peer、client to server）
fundunmental mode（抽象层面，主要用于分析某些特定问题 => 针对下面3个问题）
同时，由于分布式系统没有统一的时钟，所以一切交互基本都是以消息来进行的，针对这种通信方式，提出三种mode应对常见问题
interaction mode
failure mode
security mode
回顾一下第一章提到的一些分布式系统主要难点和威胁
- 多样性，例如整个系统中，有些comp会有很高的access load，有些又很低，甚至断开（e.g. mobile computer)，有些又对带宽要求很高
- 分布式系统中各个节点的系统环境多样，例如不同的OS，甚至Mobile
- 内部问题，例如内部各node时钟不一致，某些mode的SW、HW failure，数据同步冲突等等
- 外部问题，各种安全领域的***等等
Physical Mode
1. 最基本模型（baseline physical mode）
最基本最经典的模型，可扩展的一组计算机，链接在一个网络上面，靠消息通信
（an extensible set of computer nodes interconnected by a computer network for the required passing of messages）
基于此，有以下的扩充
2. Early distributed systems
80年代初，随着局域网，特别是以太网的兴起而产生，主要特点为local网络上连了10-100台机器，有限的互联网访问同时内部提供有限的服务例如共享打印机，文件服务器等等，而对于server QoS的关注还处于非常早期的阶段；
3. Internet-scale distributed systems
这一波，是随着90年代互联网的兴起，借助互联网的把分布式系统彻底的在global范围之内分布式起来，例如Google的服务
在这个阶段，“多样性”（heterogeneity）的问题变得突出起来，也产生了一些例如CORBA之类的中间件技术来应对这些多样性问题
4. 当代分布式系统（Contemporary distributed systems）
在3的基础上，结合了例如mobile，物联网，云计算等新兴技术
Architechtual Mode （分布式系统体系结构）
先说分布式系统的“构成实体”
最简单的模型中，构成分布式系统的实体就是Node（Server）；如果再细看一层，实际是Node中的Thread；
但是从实现的角度，这种分类还是太粗，于是有下面的不同形式
Object
在基于object为基础构建的分布式系统中，首先是用“面向对象”思维把整个系统抽象成不同的object
object提供接口供外部访问，具体的访问方法通过IDL（Interface Defination Language）来描述 => 第5&8章有更详细的描述
Component
从发展的角度，基于Component为基础而构建的分布式系统是为了解决上面“object为基础的系统”的问题而产生的（什么问题？）
建立在问题域基础上，把一些相关的object组合形成Component，同样提供接口供外部访问 => 与object-based的系统不同的是，Component-based的系统中，对外部依赖的描述比较严格 => 显式的描述了自己component正常工作时需要的外部依赖，从结构化系统设计的角度讲，这是有利于例如第三方开发独立的Component；
第8章有更详细的描述
Webservice
逻辑和上面的一样，封装之后通过接口提供功能
区别或者说优点在于，通过web技术提供更加“公共”的接口，例如URL和XML-based msg exchange
在实际应用中，webservice 经常和“通过object or component-based的”其他App结合起来，提供value-added service => 不同business之间的集成 => chapter9有更多的描述
上面是从“构成实体”角度的描述，下面，从各实体之间“交互、通信”角度
三大类：interprocess（进程间通信）；remote invoke（远程调用）；indirect communication（pub-sub？）
interprocess
主要指的是提供send/rec 原语API进行消息的收发，或者更加common Internet API （socket） => 第四章有更详细介绍
remote invocation
远程调用，首先分两大类（1）direct communication -> 交互双发同时存在 （2） indirect -> 双发不一定同时存在
第一类direct communication，包括以下几种方式（第五章有更详细的介绍）
- Request-reply protocols
这个，是最原始的方式，也是下面两种的基础
曾经（也许是曾经）主要用在client-server模式中，client发消息给server让server做些事情并返回结果
通常消息里面会带上encode成二进制的operation，以及相应的参数；通常返回结果的消息也是encode成二进制 byte
=>通常在对性能要求很高的嵌入式系统中会采用这种方式；而其他的系统，则通常采用下面的两种方式
（注意HTTP其实也是用的这种方式）
- Remote procedure calls （so called RPC）
提供一个底层的RPC系统，使得本(client)程序调用远程(server)上面的procedure，就像调用本地的一样
RPC系统负责屏蔽中间的复杂性，包括encoding/decoding 参数和返回结果，传输消息等等
（具体技术再看一下）
- Remote method invocation （RMI）
based on RPC，但是拓展到OO领域，使得local的object可以调用远程object的methods => 第五章又更详细介绍
第二类，indirect communication
两种典型场景（1）sender不知道要发给谁 - space uncoupling （2）sender和receiver不同时存在 - time Uncoupling
下列几种方式应对这两种场景
- Group communication
简单的群发群收
- Publish-subscribe systems
pub sub不用多说，避免简单粗暴的群发，提高效率
- Message queues
相对于pub sub的1-N 模式，msg queue是1-1的
sender把消息放到receiver的queue里面去，receiver慢慢搞（避免了暂时不available的问题）
- Tuple spaces
提供一块持久化的存储空间，各process可以放任意数据结构的数据在那里进行indirect communication
具体的实现需要根据实际情况处理，似乎用的不多
- Distributed shared memory
拓展share memory的思想到分布式环境中，提供这种机制的底层架构需要很好的处理同步以及数据一致性问题，在第六章会有更具体介绍
放到表格里面总结上面的内容，如下
再从各实体之间的“角色，职责”的角度分析
两种
client-server
没什么可多说的，处理略微提一下，对一个“server”来说，可以同时是“server”& “client”
举得例子是web search engine，同时“作为server，给web browser提供服务的同时，也作为client -> 爬虫，去抓web上面的网页信息”
peer-peer
最初出现的一个原因是为了解决client server结构中扩展性差的问题 => server会成为scaling过程中的瓶颈
=> 一个典型的例子就是BT下载的思想，第十章就详细介绍这种结构如何设计工作
上面介绍了分布式系统中的“逻辑实体”“实体之间的通信方式”“实体之间的角色和职责”，
下面说说如何map这些逻辑实体到具体的物理机器
这个问题没有具体的通用性指导原则，只有几个比较宏观的策略性原则可供考虑，结合实际情况做相应的设计
（为什么不能有统一原则？需要考虑实体之间的通信方式，当前物理机的load以及可靠性等等一系列和现场环境相关的问题）
- mapping of services to multiple servers;
如字面意思所述
- caching;
一个例子例如通过web proxy 来cache远端server的内容
- mobile code;
另一个典型的名字叫Applet
简单流程如下
解决什么问题呢？ => 在某些应用场景下，server希望client端能够实时的得到更新的信息（例如股票软件希望client端及时得到更新的价格）
在这种场景下，传统的CS架构肯定没问题，但如果希望轻量的BS也能support，单靠一个浏览器就不够了，于是有了Applet这种东西
同时，也带来安全问题，通常浏览器会限制applet访问local的任何资源。
- mobile agents.
感觉和Applet类似，提到的一种应用例如“installation agent”
Mobile agents might be used to install and maintain software on the computers within an organization or to compare the prices of products from a number of vendors by visiting each vendor’s site and performing a series of database operations.
下面，再换个角度分析 => 传统的“架构”层面 （例如分层） => 书上叫Architectural Pattern
叫“架构模式”也许更加合适（类比与“设计模式”）
=> 在解决特定问题的时候，值得参考的架构设计模式。
Layering Arch
常说的“分层”，底层给上层提供service => 换句话说，隐藏下层的实现细节，抽象出简单的service 接口提供给上层
简单图示如上，其中提一下Middleware的定义：
- 屏蔽底层多样性，向App的编程人员提供“简单编程模型”
（mask heterogeneity and to provide a convenient programming model to application programmers）
- 上面的“简单编程模型”通常包括
- 远程过程、方法调用（RPC、RMI）
- 进程间通信
- 共享数据管理等等，后面会细表
Tiered Arch （居然和Layering说的不是一回事 => 同一件事情的不同方面）
相对于Layering，Layering更多的是逻辑层面对整个软件的分层
而当提到“Tier”的时候，更多的是指，如何把上面的logic layer放到具体的物理机器上面
例如下图所示的3-layers SW （表示层、商业逻辑层、持久化层），落实到Tier的时候，可以有2 tiers or 3 tiers两种方案
没什么可多说的，书上提到了AJAX的例子，Google Map就是AJAX实现的一个典型
整个屏幕被分割为256x256的tiles，每一块的刷新实际都是浏览器端AJAX往后台请求新数据的过程
Thin Client
见名识意
除了BS架构，另外一种常用技术是通过VNC提供远程桌面访问的方式实现thin client
其他常见的模式（other commnly occuring pattern）
- proxy
主要用在RPC或者RMI中，做一个local的proxy，提供和远程过程/方法一样的接口
这样local程序对proxy的操作就如同对远端object的操作一样 => 第五章详细介绍
- brokerage
- reflection
反射？
关于Middleware的分类
后面章节会有更多介绍，这里提到的一点就是，APP通常不能完全依赖middleware来完成所有的事情，例如可靠的通信机制，经常需要在middleware提供的功能之外，APP需要做额外的事情。
Fundamental Models （基础设施模型）
说的是什么呢？
上面在Architectural Model中提到的任何一种模型，在具体实施的时候都不可避免的会碰到一些问题，例如performance、reliability、security等等
我们称之fundamental properties，本节谈谈这方面的设计。换个说法：阐述清楚在设计一个分布式系统的时候，所有需要考虑到的assumption，以及如何考虑这些assumption。
具体说，本节从3个角度考虑这些fundamental properties
1. interaction， 例如考虑interaction model的时候，需要考虑消息传输的延时，同步等
2. failure，分布式系统中任何一个节点出现错误咋办
3. security，可能的安全问题，以及如何应对设计
Interaction Model
从分布式系统各“进程间交互”的角度分析模型，主要从下面几方面考量
1. 通信通道的特征 （latency、bandwidth、Jitter）
Communication Channel 的特点
Latency- 从发出到收到的时间间隔
实际分析中包括比如
“实际信道传输时间”
“因为网络阻塞的等待时间 - 例如以太网原理中的冲突检测等待重发机制”
“OS的消息收发程序的处理时间 - 和CPU load有关”
Bandwidth
没啥好说的
Jitter
the variation in the time taken to deliver a series of messages.
确保一系列消息连贯发送 => 主要在video、audio领域用到
2. 缺乏统一的时间
没啥好说的，上次十四章里面都说了
3. 关于Interaction Model的两种类型 - 同步model和异步model
同步模型
基本假设：程序的每步执行都在有限的时间内完成；所有消息的传送也都在有限时间内完成；每个进程都有local clock并且漂移速度可控
在实际应用中，定义这些上下限很容易，但是真的控制在这上下限之内却是很困难；通常做法是需要确保有足够的CPU资源和网络带宽来保证；
（同步模型中，通常可以用timeout来判断是否执行失败）
异步模型
异步模型，完全相反于同步模型，上面的三个限制在异步模型中都不存在
4. 事件排序
就是十四章提到的logical clock概念
Failure Model
简单讲，分布式系统中，process和communication channel都可能出错
抽象归类之后，有下面三种failure model
Omission Failure
这一类，简单讲，该做的没做。
同样，分成process & communication channel 两种
先说process omission Failure => 典型的场景是process crash了 => 官方名称“fail-stop”
别的进程通常只能通过“发给它的消息没回应”来判断这个进程是否crash
=> 在异步式的设计中，这其实不是充分条件，因为那个进程可能反应慢了或者设置没收到
而同步式的设计中，timeout可以用来判断，当对方进程在规定的时间内没有反应，认为对方crash
再说 communication omission failure
简单讲就是“消息丢了”
从原因角度讲，一般有几种可能
- send方这边的buffer满了，所以新消息没能放到发送队列里面去
- receive方buffer满了。。。。
- 网络传输问题，收到之后checksum坏了
Arbitrary Failure
“随机”错误，感觉上这种定义的错误就是通常说的“灵异事件”
例如程序莫名其妙走到了其他地方；跳过某些步骤，或者发的消息有问题，自动重发等等
Timing Failure
简单如下定义，特别是“同步式设计”的系统，或者“video、audio”等app里面
Masking Failure
这不是一种错误类型定义，这个词说的是“针对上面描述的三种常见错误model”，我们在设计service的时候，要能够预见到并mask这些错误
例如用checksum检查Arbitrary failure转化成Omission failure，然后再重传之类的
Security Model
这块主要从下面两方面考虑
1. 保护分布式系统中的进程和通信通道，例如金融系统
2. 包括对象（object）不受非法访问，例如存放用户信息的object
会出什么问题呢，通常都是下面这种方式
连在网络上的其他server，截获消息，然后伪造消息发给下家等等
第十一章有详细介绍
应对方法，简单讲，就是加密、完整性、公钥私钥的方式的认证，以及SSL、***这样的secure channel
Weighted Voting for Replicated Data, David K.Gifford 多机副本可以提高分布式系统的性能（比如可以支持多个节点的并发访问）， 但是会产生新的问题：多个副本之间可能因为修改操作导致副本内容不一致。 论文提出一个新的算法来维持副本间的数据一致性。算法通过给副本赋以投票数来实现，每个读操作需要收集事先规定的r个投票，每个写操作需要收集事先规定的w个投票，才能执行读写请求； 并且 r + w > n (n为赋给副本的总的投票数）。这样使得任何读写操作都会具有交集。使用版本号来跟踪副本内容的修改。这样任何读， 写操作都可以发现最新的更新版本。 通过对应用场景的理解（比如读多，写少）来挑战r，w，n的数值。 例子：GFS有3个副本，假设每个副本的投票为1， 即共有3个副本，则r和w可以设置为： （1）r=1， w=3 读性能高，写性能低， 适合频繁读，少量写的应用场景（大多数website) （2）r=3, w=1 读性能低，写性能高，适合频繁写，少量读的应用场景 （写log？？） （3）r=2, w=2 读写性能相当，但是比读取或者写入单一副本的性能要差而可靠性和一致性具有保证。 通过对 文件 指定 版本号来解决上面读写多个副本，发现不一致适合的冲突处理。在读写进程数已知的情况下可以使用logical time vector来排序读写操作。 |
Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency, Cary G.Gray.. 论文提出基于短时间租约的方式来控制副本的读写。系统保证在某一客户端持有租约期间整个系统不能对其进行写操作，从而保证副本数据一致性。当租约超时，比如说10s，客户端才能对primary data进行写/更新操作。其他客户端在超时后，重新从服务器取新的副本和租约时间。 通过这样的方式来保证读写一致性，以及通过在租约期间的读本地缓存而非服务器数据来提高读性能。 之后论文对这一模型进行了分析和评估（还没看） 联想到GFS中的链式更新，采用了类似的操作而非是一个全局锁的方式来保证更新的原子性。 即对某一具有三个副本的数就集，若客户端对其进行写操作，则目录服务器将会选择三个副本所在的服务器之一作为master，并赋予一个租约，此master会将写请求携带的数据以链的方式转给另外两个服务器, client <=> master <=> replica A <=> replica B。 在都写完以后，才返回成功状态给client和目录服务器。 当然这里另外一个保证机制是允许有中断的或者写了部分的数据存在，客户端在读取数据时，会进行校验和忽略只有部分正确或内容corrupted的记录存在而继续读下一条。 |