独立计算机的集合,对外呈现一个单一的、一致的系统。
Economics 经济性 |
微处理器能提供比大型机更好的性价比 |
Speed 速度 |
分布式系统能提供比大型机更强的计算能力 |
Inherent distribution 固有的分布性 |
有一些应用包含物理上分布的机器 |
Reliability 可靠性 |
当某台机器崩溃时,整个系统仍能正常工作 |
Incremental growth 可扩展性 |
计算能力逐步增加 |
在大多数情况下,分布式系统会根据特定的架构风格去部署,这样的风格并不是在所有情况下都是最优的,因此需要动态适配中间件的行为。
Code segment/ Data segment / Excution state
本地资源在目标处可能不可用
资源类型:
对象到资源的绑定:
Migration in heterogeneous systems
主要问题
利用在不同平台上实现的抽象机器
非持久通信:无法在下一个服务器或接收者处传递消息时,服务器将丢弃该消息
持久通信:只要传递消息,消息就会存储在通信服务器中
同步通信和异步通信
RPC概念:当机器A上的一个进程调用机器B上的一个过程,则调用进程挂起,被调用进程在B上执行。信息可通过参数或者结果传递,过程对程序员不可见。
目标:让远程调用在程序员看起来是本地的普通调用。
(1) 客户端(client)以本地调用方式(即以接口的方式)调用服务;
(2) 客户端存根(client stub)接收到调用后,负责将方法、参数等组装成能够进行网络传输的消息体(将消息体对象序列化为二进制);
(3) 客户端通过sockets将消息发送到服务端;
(4) 服务端存根( server stub)收到消息后进行解码(将消息对象反序列化);
(5) 服务端存根( server stub)根据解码结果调用本地的服务;
(6) 本地服务执行并将结果返回给服务端存根( server stub);
(7) 服务端存根( server stub)将返回结果打包成消息(将结果消息对象序列化);
(8) 服务端(server)通过sockets将消息发送到客户端;
(9) 客户端存根(client stub)接收到结果消息,并进行解码(将结果消息发序列化);
(10) 客户端(client)得到最终结果。
e.g. 服务端挂掉/ 服务端更新而客户端还用的老版本
解决方案:使用 返回值(-1)、exception、signal等代表异常
客户端设置一个timer,超时重发
客户端设置一个timer,超时则重发;对于不幂等的请求,为请求分配序号,服务器区别不同的请求
问题:计算在服务端进行却没有接收计算结果的一端(孤儿),浪费了计算资源,并且可能在计算时还会锁定数据;还可能导致混淆,因为客户端重启后重新调用RPC可能收到上一个RPC的结果。
解决方案:1)extermination:在客户端存根发送RPC前,将操作记录在安全存储的 log entry上,重启后,查看 log entry 然后将 孤儿终止(为每个RPC写 log entry 代价较高,如果网络切分了也无法终止孤儿)2)reincarnation:给时间划分不同的时期,当客户端重启时,开始一个新的时期,并将这个消息广播出去,服务器收到这个消息时,就终止任务的计算。3)expiration: 给rpc执行一个标准的时间段,未完成任务需显式申请附加配额。
客户端如何定位服务器?一种解决方案是将服务器地址写死在代码里面,这样不灵活;更好的方式是动态绑定:当服务器开始执行时,发送一个消息给binder 告诉自己所能提供的接口,然后当客户端第一次调用RPC时,询问binder服务器的位置,然后再进行操作。
动态绑定过程
优势:
缺点:
同步:sender 被阻塞,直到消息存储在receiver的本地缓存或receiver接受到消息为止
异步:sender 发送信息后继续工作,消息存储在sender 端或着第一通信服务器的的本地缓存
持久性:只要将消息传递到接收方,消息就存储在通信系统中。
持久性消息也称为消息队列系统,sender和receiver都有自己的队列,当sender将消息放到receiver消息队列中时,receiver可以不是活跃状态,反之亦然。
非持久性:消息被sender放到网上,如果其无法传递给下一个通信主机则丢弃。
面向流的通信(buffer、packet不放连续帧、复用/解复用)
数据流是一种支持等时数据传输的面向连接的通信工具
特点:1)单向 2)通常只有单个来源多个接收者 3)接收者或者源是硬件包装器 4)简单的流:音频或者视频 5)复杂的流:音频视频组合
Qos:1)传输数据所需的比特率 2)建立会话之前的最大延迟 3)端到端的最大延迟(数据单元到达对方的最大时间)4)最大延迟的方差或者抖动 5)最大往返延迟
在单cpu系统中,可以使用信号量等方法解决互斥、同步问题,分布式系统中由于没有共享内存这些方法是不起作用的。在分布式系统中,如果发生两个事件,很难知道哪个先发生,因为两个时钟的差异、计算机时钟受时钟漂移影响,所以需要时钟同步来保证时钟的相对一致
时钟同步不是必须的,如果两个进程没有交互,他们的时钟可以不同步,重要的不是所有流程都确切的约定在几点,而是他们同意事件发生的顺序。
逻辑时钟:仅考虑节点间的交互在事件的发生顺序上达成一致,而不考虑时钟是否接近实际时间的算法
物理时钟:内部时钟不仅要一样,而且也要接近实际时间
服务器和客户端之间通过二次报文交换,确定主从时间误差,客户端校准本地计算机时间,完成时间同步,有条件的话进一步校准本地时钟频率。
流程如下:
RTT(Round Trip Time)= (t4-t1)-(t3-t2). RTT表示从发送到接受数据包的时间。假设来回网络链路是对称的,即传输时延相等,那么可以计算客户端于服务器之间的时差D为 (t2-t1)- RTT/2, 所以客户端在自己当前时间上加上误差D就可以校准时间。同时为了提高准确率,可以发送多次请求,计算RTT的平均值。
给每个事件e 一个时间戳C,满足下面两个属性:1)如果事件 a 和事件b 在同一个进程里(不同进程分布在不同机器上),并且a 先于b,只需要C(a) < C(b) 。 2)如果a 发送一个消息m,而b接受消息m,则必须满足C(a) < C(b)。
因为没有全局时钟,可以为每个进程维护一个逻辑时钟。
每个事件对应一个Lamport时间戳,初始值为0
这样保证了事件的偏序关系,但仍然存在不同进程中的两个事件同时发生,因此可以为每个进程编号,在C(a) == C(b)的情况下,若a进程号小于b进程号,则认为a先于b,从而保证全序性(这里a,b的先后并不重要,只是这样可以对全局事件进行排序)
total order multicasting (全序组播)(基于队列,4步:顺序接受;发送消息;接受消息,放入队列,发送ACK;应用消息)
如何保证分布式系统中各个子系统都按相同的顺序执行一组操作?一个等价的问题就是如何在分布式系统下实现全序组播。
使用进程Id 保证不同进程的逻辑时钟不一致,C(a).i (i是进程号) 发生在C(b).j 之前可以表示为: C(a) < C(b) 或 C(a) == C(b), i < j 。
实现细节:
实现原理:
lamport lock 特点
向量时戳就是解决这个问题的。
集中式算法:仿照单机处理系统中的方法,选举一个进程作为协作者,由这个协作者调度对共享资源的访问。
当一个进程要访问共享资源,它要向协作者发送一个请求信息,说明它想要访问哪个资源。如果当前没有其他进程访问资源,协作者就发送准许的应答消息。
特性:
缺点:
缺点:
将进程组织为逻辑环,然后传一个令牌,拥有令牌的可以访问资源
Bully Algorithm(3步:优先级组播;出局/接管;没收到接管获胜)
每个进程都有自己的优先级,问题是如何找到最高优先级的进程
Election in a ring
任何进程都可以发送选举消息,然后这个消息不断往下传,每传到一个节点大家都将自己的优先级信息附加上去,最后回到选举发起者那里,然后找到优先级最高的那个作为协调者,将消息传播出去。
优势 :可靠性、性能
不足:复制透明度;一致性问题。
真正实现一致性,需要考虑数据更新时如何进行实际的分发,副本的位置、更新的方式,更新的速度
数据一致性模型
数据的共享是通过分布式共享存储器、分布式共享数据库或者分布式共享文件系统实现的。
需要保证数据更新的同时,所有副本也同样同时更新,但显然是不可能实现的
允许任何读写操作的交叉执行,但是要保证所有进程能够确认统一的执行顺序,不会存在不同进程的执行顺序得到不同的结果的现象。
存在严重的性能问题,对于任何顺序一致性存储,提高读操作性能必降低写操作性能
实现顺序一致性:对于写操作,使用全序多播;对于读操作,立即返回本节点上对应变量的值。
线性一致性相对于顺序一致性增加了时间戳顺序的要求,更加严格
弱化的顺序一致性,顺序存储的因果一致性定位为:所有进程必须以相同的顺序看到具有潜在因果关系的写操作。不同机器上的进程可以以不同的顺序被看到并发写操作。
实现因果一致性要求跟踪哪些进程看到了哪些写操作。换句话说,因果一致性允许不同的机器以不同的顺序看到并发的写操作,但是所有机器必须以相同的顺序看到因果相关的操作。
所有进程以某个单一进程提出写操作的顺序看这些写操作,但是不同进程可以以不同的顺序看到不同进程提出的写操作。也就是说,进程不必再开始进行下一个写操作之前停止并且等待前一个写操作的完成。不同进程产生的写操作都是并发的。
它仅仅要求:对于同一个进程执行的读写序列,对于任何一个变量x的读操作read(x),读到的值都是在此读操作之前最后一次此进程发出的写操作write(x)更新的值。而对于不同节点发出的写序列,其他节点的读操作可以按任意顺序返回值。
引入同步变量s,当一个进程对变量设置值的时候,不保证其他进程什么时候能够看到值的变化,但是当执行了一次同步操作后,所有进程会看到最新的值。
使用两个同步变量ACQ和REL成对控制,释放一致性规则如下
本质上以客户为中心的一致性模型为单一的客户提供一致性保证,并不为不同客户的并发访问提供一致性保证。
Eventual consistency
如果在一段相当长的时间内没有更新操作,那么所有的副本将逐渐成为一致的。
单调读:进程在t时刻看到x,保证后续操作不会看到x的更老版本。
单调写:写操作必须完全串行执行,不能交叉。
写后读(read-your-writes consistency):一个写操作总是在同一进程后续读操作之前完成,不管这个后续读在什么位置。
读后写:对数据项x的任何后续写操作,保证发生在于x读取值相同或比之更新的值上。
三种数据拷贝的类型:永久复制(多个拷贝分布在LAN的多个server上;);server发起的复制;client发起的复制(主要是cache)
更新传播的三种方式:仅传播一个更新通知;传播更新后数据;传播更新操作种类;
要求客户在读写一个复制的数据项之前请求半数以上的服务器并多的返回的版本号,以确定数据的最新版本。假设所有副本数量加起来等于V
每个操作需要获得一个读的法定数量Vr 和写的法定数量Vw,必须遵循以下规则:
使用冗余来掩盖故障:对其它进程隐藏故障的发生。
一种不需要大量关键组件同时运行的设计。
复制进程的管理(基于主进程|选举|层级;复制写|法定数量协议|平等)
基于主进程的复制:主进程负责协调所有更新;如果协调者挂了,备份接管(通常需要选举);进程之间是层级的组织方式。
复制写:主动复制,基于法定数量协议;平等组织;没有单点失败
设计问题
通信是可靠的但是进程不可靠。(通信不可靠的两军问题无解,最多只能降低不可靠性)。
问题定义
n 个不同地点的蓝色将军想要达成共识,但是其中的m个是叛徒。那么忠诚的将军们能否在同一个行动上达成共识?这个与K容错是有区别的。K容错是正确节点都会得到相同结果,而拜占庭将军问题是正确节点也会存在有不同结果。
算法步骤
第一步:每个军将告诉其他所有n-1个将军自己的兵力(真假未知)。
第二步:每个将军收集消息形成一个向量。
第三步:每个将军将自己的向量发送给其它所有将军。
第四步:每个将军检查新收到的向量的第i个元素。把多数值保留下来,得到一致结果。
结论:具有m个故障进程的系统中,只有存在2m+1个正确的进程才能达成一致,也即共有3m+1个进程。
Byzantine Generals Problem
设计一个协议,一个司令要送一个命令给他的n-1个副官,使得
IC1. 所有忠诚的副官遵守同一个命令。(一致性)
IC2. 假如司令是忠诚的,则每一个忠诚的副官遵守他送出的该命令。(准确性)
约定:忠诚的将军将遵守协议,而叛徒则可能破坏协议,尽可能的干绕其它人的判断。叛徒是匿名的。而且最后不需要确定谁是叛徒。拜占廷将军问题就是要让爱国的将军达成一致,而不是找叛国的将军。
Oral Message Algorithm (OM算法)
叛徒少于1/3,拜占庭问题可解
A1) 传送正确
A2) 接收者知道是谁发的
A3) 沉默(不发信息)可被检测
OM(n,0):
OM(n,m):
发生故障后恢复到正确的状态
独立检查点
协调检查点
所有的进程进行同步,以共同将其状态写入本地稳定存储,从而形成全局一致状态
两个算法:
two-phase blocking protocol
一种计算能力,提供了计算资源与底层结构之间的抽象,使用户可以通过网络方便的、按需使用的来对一个共享资源池进行迅速的配置、部署与使用,并且只需要很少的管理以及与服务商的交互。
软件即服务SaaS (Software as a Service) |
Salesfoce online CRM服务 |
平台即服务PaaS(Platform as a Service) |
Google App Engine Sina App Engine(SAE) |
基础设施即服务IaaS(Infrastructure as Service) |
Amazon EC2、S3 阿里云 |
虚拟化是由位于下层的软件模块,将其封装或抽象,提供软硬件的接口,使得上层的软件可以直接运行在这个虚拟的环境,和运行原来的环境一样。
虚拟化特点 |
为云计算带来的好处 |
封装与隔离 |
保证每个用户有安全可信的工作环境 |
多实例 |
保证较高的资源利用率 为服务器合并提供基础 |
硬件无关性 |
整合异构硬件资源 可实现虚拟机迁移,使资源调度、负载平衡容易实现 |
特权功能 |
入侵和病毒检测 |
动态调整资源 |
细粒度的可扩展性 |
基本思想:把云计算平台从移动核心网络内部迁移到移动接入网边缘
概念
集中式云环境缺点:
不易扩展、集中而脆弱、安全信任难以实现、更易受到攻击、控制设备时延高
优点
措施:把大部分计算沉降在靠近设备的边缘,小部分连接远处的云端
云计算与边缘计算的结合
可能结合的一种架构
特点