欢迎关注Hadoop、Spark、Flink、Hive、Hbase、Flume等大数据资料分享微信公共账号:iteblog_hadoop
  1. 文章总数:961
  2. 浏览总数:11,484,580
  3. 评论:3873
  4. 分类目录:103 个
  5. 注册用户数:5843
  6. 最后更新:2018年10月17日
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
iteblog_hadoop
大数据技术博客公众号bigdata_ai
大数据猿:
bigdata_ai

分布式系统调用的三态

在传统的单机系统中,我们调用一个函数,这个函数要么返回成功,要么返回失败,其结果是确定的。可以概括为传统的单机系统调用只存在两态(2-state system):成功和失败

然而在分布式系统中,由于系统是分布在不同的机器上,系统之间的请求就相对于单机模式来说复杂度较高了。具体的,节点 A 上的系统通过 RPC (Remote Procedure Call) 方式与节点 B 上的系统进行通信,在这个请求结果存在三态(3-state system):也就是成功、失败和超时,不要小瞧超时这个状态,因为它几乎是所有分布式系统复杂性的根源。

  • 如果节点 A 上的系统收到节点 B 系统返回的消息,并且消息能够表明执行成功,则该 RPC 的结果即为成功状态;
  • 如果节点 A 上的系统收到节点 B 系统返回的消息,并且消息能够表明执行失败,则该 RPC 的结果即为失败状态。
  • 上面两种情况我们都可以非常容易的处理。但是,如果节点 A 上的系统在给 节点 B 上的系统发送完 RPC 调用,并且在一定的时间内没有收到节点 B 上的系统返回消息,本次调用就超时了。此时的 RPC 的结果即为超时状态。

对于超时的请求,我们无法得知该请求是否被节点 B 上的系统成功执行了。这是因为

  • 节点 A 上的系统与节点 B 上的系统进行通信的过程中可能出现了消息丢失,这时候节点 B 上的系统根本就不知道有其他系统与其进行通信。
  • 分布式系统调用的三态
    如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop
  • 节点 B 上的系统接到调用请求的消息,并且进行完相关的计算,这时候将结果通知节点 A 上的系统过程中出现消息丢失(如下图的左边部分)或者在将要发送通知消息的时候节点 B 突然宕机(如下图的右边部分),这些都将导致消息发送失败。
分布式系统调用的三态
如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop

分布式系统一般需要区别对待 RPC 的成功、失败和超时三种状态。解决超时可以如下处理

  • 当出现超时时,可以通过发起读取数据的操作以验证 RPC 是否成功。
  • 另一种简单的做法是,设计分布式协议时将执行步骤设计为可重试的,也就是说计算或写操作具有幂等性。例如覆盖写就是一种常见的幂等性操作,因为重复的覆盖写最终的结果都相等。如果使用可重试的设计,当出现失败和超时时,一律重试操作直到成功。这样,即使超时的操作实际上已经成功了,重试操作也不会对正确性造成影响,从而简化了设计。
本博客文章除特别声明,全部都是原创!
转载本文请加上:转载自过往记忆(https://www.iteblog.com/)
本文链接: 【分布式系统调用的三态】(https://www.iteblog.com/archives/2340.html)
喜欢 (8)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!