也谈分布式系统中的网络模型和故障模型

1. 写在前面

分布式系统中的网络模型和故障模型是个老生常谈的问题了。

  • 关于网络模型,相信大家都知道分为:同步网络和异步网络。
  • 对于故障模型,大家可能会有点懵。因为无论是在各种教材上还是在各种博客中关于该模型的划分都很杂、很乱,甚至相互之间有些矛盾。举例来说,大家可能看到过下面这两张图。这两张图分别对故障模型进行了划分,但划分结果却迥然不同。
    在这里插入图片描述
    在这里插入图片描述

此外,大家有没有思考过这个问题:

  • 网络模型和故障模型的关系是什么?大家似乎在讨论故障模型的时候,直接就忽略网络模型了

在本篇博客中,我们也想谈谈这两个模型。对于故障模型,我们努力将现有的各种划分结果进行统一,使得我们的划分结果更加系统科学。此外,我们也尝试从新的角度理解网络模型,并回答网络模型和故障模型的关系。

2. 再理解网络模型

网络模型分为:同步网络和异步网络,两者的不严谨定义分别如下所示:

  • 同步网络:网络中消息传递的延迟有上限,节点的处理延迟延迟有上限
  • 异步网络:网络中消息传递的延迟没有上限,节点的处理延迟无上限

这里需要指出的是,尽管“网络模型”这个词字面上只包含了“网络”,但其实际上对节点处理延迟也进行了规定。
此外,在我们看来,同步网络和异步网络的最大区别在于故障的可检测性。具体来说,在同步网络中,其他节点或网络的故障可以通过 超时(ping/timeout) 进行检测;而在异步网络中,这些故障是无法进行检测的。
由于我们只能通过**超时(ping/timeout)**在同步网络中进行故障检测,可检测的故障也只有节点崩溃网络链路断开这种错误(就故障而言,节点崩溃网络链路断开是等价的,这在3.1节种将进行讨论)。
记住这个结论,该结论将在第4节中用到。

2.1 一个疑问

看久了故障模型和网络模型,我曾经有的一个疑问是:

同步网络中是否保证了网络链路不会发生断开?

答案是不保证。同步网络中也会出现链路断开,因此才需要使用**超时(ping/timeout)**进行检测。当然,异步网络中更不会保证链路不断开。

3. 故障模型的划分

综合比较多个划分结果,我们将故障模型重新划分如下图所示,相应的解释如下表。
在这里插入图片描述

故障划分解释
Byzantine failure节点可以任意篡改发送给其他节点的数据
Authentication detectable byzantine failure (ADB)Byzantine failure的特例;节点可以篡改数据,但不能伪造其他节点的数据
Response failureADB的特例,节点可以返回错误数据,但只能返回受限的错误数据
Performance failure又名timing failure, 节点未在特定时间段内收到数据,即时间太早或太晚
Omission failurePerformance failure的特例;节点收到数据的时间无限晚,即收不到数据
Crash failureOmission failure的特例;在omission failure的基础上,增加了节点停止响应的假设,也即持续性地omission failure
Fail-stop failureCrash failure的特例;在Crash failure的基础上增加了错误可检测的假设

从图中我们可以看出,越在外层的错误模型(如Byzantine failure)所作的假设越少,越在内层的错误模型(如Crash failure)所作的假设越多。也即,一个在内层模型中可行的共识方案未必可以在外层模型中可行。

以下,我们分别讨论故障模型的一个疑问和两个分类。

3.1 一个疑问

一直以来,我对故障模型存在一个疑问:

故障模型是针对节点还是针对网络而言的?也即:故障模型中的故障讨论的是节点故障还是网络故障

我思考的结论是两者(节点故障和网络故障)都包括
我个人对此的理解是:从分布式系统中节点的角度来看,节点故障和网络故障是无法区分的,甚至一定程度上是等价的。举例来说:“网络延迟”和“节点处理速率慢”等价;“网络链路断开”和“节点宕机”等价;“网络链路中路由器篡改数据”和“节点恶意篡改数据”等价。因此,故障模型中的故障是将节点和网络包含在一起进行讨论的。

这里顺便对Omission failure故障模型的含义进行深入讨论。
Omission failurePerformance failure以及Crash failure进行对比,Omission failure故障模型的含义包括两个层面:

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

由于我们已经说明了节点故障和网络故障的等价性。

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

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

3.2 按照故障发生的领域分类(Domain of failure occurrence)

3.2.1 值故障 (Value failure)

值故障的含义是节点接收到的数据值发生了故障。

  • Byzantine failure
  • Authentication detectable byzantine failure (ADB)
  • Response failure
3.2.2 时间故障 (Time failure)

时间故障的含义是节点接收到数据的事件发生的故障。
这里的time failure和上表中的Performance failure那一行中的timing failure不同。这里将最里层的4个故障统称为time failure

  • Performance failure
  • Omission failure
  • Crash failure
  • Fail-stop failure

3.3 按照用户对数据的感知分类(Perception by the system users)

3.3.1 非一致性故障 (Inconsistent failure)

非一致性故障是指其他节点从同一节点中接收到的数据是不一致的。

  • Byzantine or arbitary failures
  • Authentication detectable byzantine failure (ADB)
3.3.2 一致性故障 (Consistent failure)

一致性故障是指其他节点从同一节点中接收到的数据是一致的,在此基础上出现的其他故障。

  • Response failure
  • Performance failure
  • Omission failure
  • Crash failure
  • Fail-stop failure

4. 网络模型和故障模型的关系

4.1 再讨论Fail-stop failure模型

在开始网络模型和故障模型的关系之前,我们先讨论一下Fail-stop failure这个特殊的故障模型。
前面我们介绍了Fail-stop failure这个模型,其是在Crash failure模型的基础上增加了故障可检测的假设。回顾我们在第2节中的理解:同步网络和异步网络最大的区别在于故障的可检测性。
因此,Fail-stop failure模型本质上是在Crash failure模型的基础上增加了“同步网络”的假设。
那么为什么在其他几类模型中不增加“同步网络”的假设,使其演变为另一种模型呢?

4.2 是否可以对其他模型增加“同步网络”的假设?

回顾我们在第2节中的结论,同步网络中可检测的故障只有节点崩溃或网络链路断开这种故障。而这种故障正对应于Crash failure
也就是说,在除Crash failureFail-stop failure之外的其他5类故障模型中,同步网络和异步网络的假设并不会对模型产生影响
因此,无需对其他模型怎加“同步网络”的假设。

4.3 网络模型和故障模型的正交性

一定程度上来看,网络模型和故障模型是正交的。但,是否将不同的网络模型和故障模型进行叠加,需要考虑其叠加后的意义。
正如4.2节中所说,在除Crash failure之外的其他5类故障模型,叠加网络模型不会分化出新的模型。因而,我们在众多的教材和博客中,都不会看到它们相叠加的讨论。

参考链接

  1. Fault tolerance, Chap08
  2. Failure modes in distributed systems
  3. Failure semantic - Wikipedia
  4. Understanding omission failure in distributed systems
  5. Modes of failure
  6. Failure modes and models
  7. What we talk about when we talk about distributed systems
  8. Crash Recovery with Partial Amnesia Failure Model Issues
  9. 分布式系统中的网络模型和故障模型
  10. 分布式系统一致性的发展历史 (二)
  11. Faults and fault-tolerance
  • 6
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
下面是一个基于RNN模型分布式系统故障诊断系统数据清洗的代码示例: ```python import pandas as pd # 读取原始数据 data = pd.read_csv('system_data.csv') # 数据清洗 # 假设原始数据包含了CPU利用率、内存利用率和网络流量等特征,以及对应的故障标签 # 在数据清洗过程,我们可以处理缺失值、异常值和重复值等问题 # 处理缺失值 data.dropna(inplace=True) # 删除包含缺失值的行 # 处理异常值 def remove_outliers(df, columns): for column in columns: q1 = df[column].quantile(0.25) q3 = df[column].quantile(0.75) iqr = q3 - q1 lower_bound = q1 - 1.5 * iqr upper_bound = q3 + 1.5 * iqr df = df[(df[column] >= lower_bound) & (df[column] <= upper_bound)] return df data = remove_outliers(data, ['cpu_utilization', 'memory_utilization', 'network_traffic']) # 处理重复值 data.drop_duplicates(inplace=True) # 保存清洗后的数据 data.to_csv('cleaned_system_data.csv', index=False) ``` 在这个示例,我们假设原始数据文件名为`system_data.csv`,包含了CPU利用率、内存利用率和网络流量等特征,以及对应的故障标签。首先,我们使用Pandas库读取原始数据文件。然后,我们进行数据清洗的步骤。 在数据清洗过程,我们首先处理缺失值。在示例,我们使用`dropna()`函数删除包含缺失值的行。 接下来,我们处理异常值。在示例,我们定义了一个`remove_outliers()`函数,通过计算特征列的四分位数和箱线图范围,来识别并移除异常值。 最后,我们处理重复值。通过使用`drop_duplicates()`函数,可以移除重复的行。 最后,我们将清洗后的数据保存为`cleaned_system_data.csv`文件。 需要注意的是,数据清洗的具体方法和步骤可能因数据类型和问题而有所不同。在实际应用,可能需要根据具体情况对数据进行更复杂的清洗处理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值