分布式系统及云计算原理

i_zyh

已于 2024-12-03 15:32:15 修改

阅读量1.4k

点赞数 20

文章标签：云计算分布式

于 2024-11-16 18:30:38 首次发布

本文链接：https://blog.youkuaiyun.com/i_zyh/article/details/143743038

版权

一、分布式系统的特征

1.1 分布式系统简介

1.分布式系统定义：

一个其硬件或软件组件分布在连网的计算机上，组件之间通过消息进行通信或动作协调的系统。

2.显著的特征：①并发 ②全局时钟 ③故障独立性

3. 构造分布式系统的主要动力之一：是来源于 资源共享协作

1.2 部分术语

服务—表示计算机系统中管理相关资源并提供功能给用户和应用的一个单独的部分
服务器----是指在连网的计算机上的一个运行的程序（进程），这个程序接收来自其他计算机上正在运行的程序的请求，执行一个服务并适当地做出响应。
客户 ——发出请求的进程称为。（客户和 服务器指的是进程而不是运行客户或 服务器的计算机）

二、系统模型

2.1 简介

1.分布式系统的困难和威胁：①使用模式的多样性 ②系统环境的多样性 ③内部问题 ④外部威胁

2.物理模型：描述系统的最显式的方法，系统的硬件组成

3.体系结构模型：描述系统的计算元素执行的计算和通讯任务

2.2 物理模型

分布式系统的趋势

◦泛在互联网技术

◦移动和无处不在的计算

◦分布式计算作为公共设施-云计算

2.3 体系结构模型

1.用独立指定的组件以及这些组件之间的关系来表示的结构

2.主要设计目标：

可靠性
可管理性
适应性
性价比

2.3.1 体系结构四个关键问题

通信的双方参与者具体是什么？
它们如何保持通信，使用什么通信范型？
扮演什么角色，承担什么责任？
如何被映射到物理分布式基础设施上？

一、体系结构元素——参与者

从系统角度来看，分布式系统中通信的实体通常是进程。
从编程观点来看，进程可能对应了一个对象Object。

二、体系结构元素——通信范型（分布式系统中实体如何通信）

进程间通信
进程调用
间接通信

1.进程间通信：指用于分布式系统进程之间通信的相对底层的支持，包括消息传递原语、直接访问由互联网协议提供的API和对多播通信的支持。

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

远程过程调用（Remote Procedure Call，RPC）：远程计算机上进程中的过程调用与本地调用一致
远程方法调用（Remote Method Invocation, RMI）：与远程过程调用类似，但仅应用于分布式对象环境，且底层细节对用户隐藏

3.间接通信：

（1）通过第三个实体，允许在发送者和接收者之间的深度解耦合

发送者不需要知道正在发送给谁（空间解耦合）
发送者和接收者不需要同时存在（时间解耦合）

（2）组通信

组通信涉及消息传递给若干接收者，是支持一对多通信的多方通信泛型

（3）发布—订阅系统

大量生产者（或发布者）为大量的消费者（订阅者）发布他们感兴趣的信息项
关键特征：中间服务---用于确保由生产者生成的信息被路由到需要这个信息的消费者

（4）消息队列

提供点对点服务
生产者发送消息到指定队列，消费者能从队列中接收消息，或者被通知队列有消息到达

（5）分布式共享（外部）存储

进程可以把任意的结构化数据项放到一个持久分布式存储空间，其他进程可以指定感兴趣的模式，从而可以在共享空间读取或者删除数据。

（6）分布式共享内存（Distributed Shared Memory，DSM）

系统提供一种抽象，用于支持在不同共享物理内存的进程之间共享数据

三、体系结构元素——角色和职责

进程相互交互完成一个有用的活动
进程在系统中扮演给定的角色
客户---服务器

1.C/S模式（主从模式）：

直接、简单，但是伸缩性差
集中化的提供服务和管理
受到计算机处理资源和网络带宽等资源条件限制大

2.P2P模式（对等体系）：

不区分客户和服务器或运行它们的计算机
所有参与进程运行相同的程序
并且在相互之间提供相同的接口集合

3.混合模式

对等方式选出主节点，之后采用主从模式

四、体系结构元素——放置placement/映射

1.对象实体如何映射到底层物理分布基础设施
2.物理分布基础设施由大量机器组成，机器通过任意复杂的网络互联
3.决定了分布式系统的特性：性能、可靠性、安全性
4.如何放置客户和服务器需要仔细设计

考虑实体间的通信模式
机器的可靠性和负载
不同机器间通信质量

静态映射：映射到多个服务器

对象将分区分部到各个服务器上
在几个主机上分别放置副本

动态映射：移动代码

位置感知的映射：

2.4 故障模型

2.4.1 故障模型

分布式系统中，进程和通信通道都可能出故障
故障模型定义了故障可能发生的方式，以便理解故障所产生的影响

越在外层的错误模型（如Byzantine failure）所作的假设越少，越在内层的错误模型（如Crash failure）所作的假设越多。
一个在内层模型中可行的共识方案未必可以在外层模型中可行。

2.4.2 故障分类

故障划分

解释

Byzantine failure

拜占庭故障

节点可以任意篡改发送给其他节点的数据

Authentication detectable byzantine failure (ADB)

Byzantine failure的特例；节点可以篡改数据，但不能伪造其他

节点的数据

Response failure

响应故障

ADB的特例，节点可以返回错误数据，但只能返回受限的错误

数据

Timing failure

时序/性能故障

有时也称为Performance failure性能故障, 服务进程做出了正确的

响应，但是这个响应在错误的时间抵达（过早或者过晚）。比如

网络产生的拥堵、请求重试等。

Omission failure

遗漏故障

Timing failure的特例；节点收到数据的时间无限晚，即收不到数

据；

对应的服务器的响应可能永远无法到达。比如产生了消息丢失。

Crash failure

崩溃故障

Omission failure的特例；在omission failure的基础上，增加了节

点停止响应的假设，也即持续性地omission failure

Fail-stop failure

失败停机故障

Crash failure的特例；在Crash failure的基础上增加了错误可检测

的假设

灰色部分是值相关故障：节点接收到的数据值发生了故障；

白色部分是时间相关故障：节点接收到数据的事件发生的故障

2.4.3 拜占庭将军问题

只能依靠不可靠通信相互交流，又不知道谁是叛徒，怎么能不受叛徒们的影响，让这些忠诚的将军快速的达到一致的作战计划。

1. 在分布式系统领域, 拜占庭将军问题中的角色与计算机世界的对应关系如下:

· 将军, 对应计算机节点；
· 忠诚的将军, 对应运行良好的计算机节点；
· 叛变的将军, 被非法控制的计算机节点；
· 信使被杀, 通信故障使得消息丢失；
· 信使被间谍替换, 通信被攻击, 攻击者篡改或伪造信息。

拜占庭将军问题提供了对分布式共识问题的一种情景化描述，是分布式系统领域最复杂的模型。

2. 拜占庭问题的重新兴起：

拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。
随着比特币和区块链的兴起，这个著名问题又重新被大家广泛研究。

2.4.4 可检测拜占庭问题——Authentication detectable byzantine failure (ADB)

是服务进程有时可能会出现拜占庭问题，但是它不会否认自己之前达成的共识。
通常是服务进程崩溃后，马上被重新启动时，会出现该问题，因为在崩溃前会根据当前情况响应一些请求，但是崩溃重启后，一些未达成共识的状态可能被丢弃，再次进行响应时，可能会跟崩溃的响应不同。

2.4.5 时序故障——忙不过来&时钟错误

对进程执行时间、消息传递时间和时钟漂移率均有要求

2.4.6 遗漏故障

是指进程或者通信通道不能完成它应该做的动作，有时也翻译为失效故障；
节点收到数据的时间无限晚，即收不到数据；
对应的服务器的响应可能永远无法到达。比如产生了消息丢失。

一、遗漏故障——信息遗漏故障

通信原语send和receive
进程p将消息m插入到它外发消息缓冲区来执行send
通信通道将m传输到q的接受消息缓冲区
进程q通过将m从接受消息缓冲区取走并完成传递来执行receive

如果通信信道不能将消息从p传递到q，那么就产生了遗漏故障（发送遗漏、接受遗漏、通道遗漏）

接收端或中间网关缺乏缓冲区
网络传输错误

二、遗漏故障Omission failure——丢三落四

遗漏故障Omission failure故障模型的含义包括两个层面：

针对某个特定消息来说，节点A可能永远无法收到来自节点B回复（即：存在消息丢失）
但对于该消息之后的消息，节点A可能重新收到来自节点B回复（即：恢复对后续消息的响应）

当故障是节点引起时，Omission failure描述了以下场景：节点B在短暂宕机后，又恢复了运转；与此同时，网络一直在正常连接。
当故障是网络引起时，Omission failure描述了以下场景：网络在短暂断开后，可能又恢复了连接；但与此同时，节点B一直在正常运转。这种场景实际上是我们熟悉的网络分区（Partition）现象。

也就是说：网络分区故障实际上是Omission failure的一个特例。

2.4.7 崩溃故障、失败停止故障

Crash failures

崩溃故障就是服务进程停止了任何响应，比如进程崩溃等。
在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure。

Fail-stop failures

当服务进程进入崩溃故障后，并且能够被别的正常服务进程检测到它的故障，则称它进入到失败停止故障。

2.4.8 故障检测

一、心跳检测法（HeartBeat）

总控节点每隔一段时间向work节点发送一个心跳包，如果一切正常，work节点就会回复总控节点的心跳包，同时心跳包中会含有work节点的机器的运行情况（如load值, cpu和IO的使用情况）。否则总控节点尝试一定次数后仍收不到回包则认为work节点出现了故障。

心跳检测法不一定可靠！

比如可能网络问题（网络中断、网络拥塞造成的所谓“瞬断” ）或者work节点繁忙未应答，总控节点认为work节点失效，但其实work节点仍在正常提供服务。在分布式系统中，这个是存在一定业务风险的。他的问题主要在于它是单方面判定节点失效。
比如，总控节点认为work节点失效，所以为服务重新选取了新的主服务节点，而判定失效的节点可能正在继续正常工作，导致"双主"问题。

二、租约机制（Lease）

授权：Lease是颁发者在一定期限内給予持有者一定权利的协议。
时限：Lease 表达了颁发者在一定期限内的承诺，只要未过期颁发者必须严格遵守 lease 约定的承诺。
续约：Lease 的持有者在期限内使用颁发者的承诺，但lease一旦过期必须放弃使用或者重新和颁发者续约。

过程：

由租约中心节点向其他节点发送 lease,若某个节点持有有效的 lease,则认为该节点正常可以供服务。
节点 A、B、C 依然周期性的发送 heart beat 报告自身状态,租约中心收到 heart beat 后发送一个 lease,表示租约中心确认了节点 A、B、C 的状态,并允许节点在 lease 有效期内正常工作。
租约中心可以给 primary 节点一个特殊的 lease,表示节点可以作为 primary 工作。
一旦租约中心希望切换新的 primary,则只需等前一个 primary 的 lease 过期,则就可以安全的颁发新的 lease 给新的 primary 节点,而不会出现“双主”问题。

租约机制的容错能力：

1.通过引入有效期,Lease 机制能否非常好的容错网络异常

Lease 颁发过程只依赖于网络可以单向通信
接收方无法向颁发者发送消息,也不影响 lease 的颁发
Lease幂等性，颁发者偶尔发送 lease 失败,颁发者也可以简单的通过重发的办法解决

2.Lease 机制能较好的容错节点宕机

颁发者宕机,则宕机的颁发者通常无法改变之前的承诺,不会影响 lease 的正确性
接受方宕机的情况,颁发者不需要做更多的容错处理,只需等待 lease 过期失效,就可以收回承诺,实践中也就是收回之前赋予的权限、身份等

3.Lease 机制不依赖于存储

即使颁发者没有持久化 lease 信息,也可以通过等待一个最大的 lease 时间的方式使得之前所有颁发的 lease 失效,从而保证机制继续有效

租约机制的局限性（一）：

Lease 机制依赖于有效期,这就要求颁发者和接收者的时钟是同步的。
一方面,如果颁发者时钟比接收者的时钟慢,则当接收者认为 lease 已经过期的时候,颁发者依旧认为 lease 有效。接收者可以用在 lease 到期前申请新的 lease 的方式解决这个问题。
另一方面,如果颁发者的时钟比接收者的时钟快,则当颁发者认为 lease 已经过期的时候,接收者依旧认为 lease 有效,颁发者可能将 lease 颁发给其他节点,造成承诺失效,影响系统的正确性。
- 对于这种时钟不同步,实践中的通常做法是将颁发者的有效期设置得比接收者的略大,只需大过时钟误差就可以避免对 lease 的有效性的影响。

租约机制的局限性（二）：

如何选择Lease的时长在工程实践中是一个值得讨论的问题
- 若 lease 时间过短,有可能造成网络瞬断时节点收不到 lease 从而引起服务不稳定,
- 若 lease 时间过长,则一旦某节点宕机异常,需要较大的时间等待 lease 过期才能发现节点异常。
- 工程中,常选择的 lease 时长是 10 秒级别。
租约中心的单点故障问题
- Zookeeper等分布式租约中心