快速失败机制&失败安全机制

这是why技术的第29篇原创文章

之前在写《这道Java基础题真的有坑!我求求你,认真思考后再回答。》这篇文章时,我在8.1小节提到了快速失败和失败安全机制。

但是我发现当我搜索”快速失败”或”失败安全”的时候,检索出来的结果百分之90以上都是在说Java集合中是怎么实现快速失败或失败安全的。

在我看来,说到快速失败、失败安全时,我们首先想到的应该是这是一种机制、一种思想、一种模式,它属于系统设计范畴,其次才应该想到它的各种应用场景和具体实现。而不是立马想到了集合,这样就有点本末倒置的感觉了。

可以看一下wiki上对于快速失败和失败安全的描述:

快速失败:http://en.wikipedia.org/wiki/Fail-fast

失败安全:http://en.wikipedia.org/wiki/Fail-safe

简而言之:系统运行中,如果有错误发生,那么系统立即结束,这种设计就是快速失败。系统运行中,如果有错误发生,系统不会停止运行,它忽略错误(但是会有地方记录下来),继续运行,这种设计就是失败安全。

本文就对比一下Java集合中的快速失败、失败安全和Dubbo框架中的快速失败、失败安全。

读完之后,你就知道Java集合中实现和Dubbo中的实现就大不一样。

没有谁比谁好,只有结合场景而言,谁比谁更合适而已。

Java集合-快速失败

现象:在用迭代器遍历一个集合对象时,如果遍历过程中对集合对象的内容进行了增加、删除、修改操作,则会抛出ConcurrentModificationException。

原理:迭代器在遍历时直接访问集合中的内容,并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化,就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前,都会检测modCount变量是否为expectedmodCount值,是的话就返回遍历;否则抛出ConcurrentModificationException异常,终止遍历。

注意:这里异常的抛出条件是检测到 modCount!=expectedmodCount 这个条件。如果集合发生变化时修改modCount值刚好又设置为了expectedmodCount值,则异常不会抛出。因此,不能依赖于这个异常是否抛出而进行并发操作的编程,这个异常只建议用于检测并发修改的bug。

场景:java.util包下的集合类都是快速失败的,不能在多线程下发生并发修改(迭代过程中被修改)。

上面的知识点我在《这道Java基础题真的有坑!我求求你,认真思考后再回答。》这篇文章中第三小节已经抽丝剥茧般的详细说明了,有兴趣的可以阅读一下:

Java集合-失败安全

现象:采用失败安全机制的集合容器,在遍历时不是直接在集合内容上访问的,而是先复制原有集合内容,在拷贝的集合上进行遍历。

原理:由于迭代时是对原集合的拷贝进行遍历,所以在遍历过程中对原集合所作的修改并不能被迭代器检测到,所以不会触发ConcurrentModificationException。

缺点:基于拷贝内容的优点是避免了ConcurrentModificationException,但同样地,迭代器并不能访问到修改后的内容,即:迭代器遍历的是开始遍历那一刻拿到的集合拷贝,在遍历期间原集合发生的修改迭代器是不知道的。这也就是他的缺点,同时,由于是需要拷贝的,所以比较吃内存。

场景:java.util.concurrent包下的容器都是安全失败,可以在多线程下并发使用,并发修改。

比如之前文章说到的CopyOnWriteArrayList:

集合部分涉及到的参考链接:https://www.cnblogs.com/ygj0930/p/6543350.html

Dubbo中的集群容错

在描述快速失败和失败安全在Dubbo中的体现之前,我们必须先说说Dubbo中的集群容错机制,因为快速失败和失败安全是其容错机制中的一种。

还是看之前出现的图片:

其中,集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker,并将这个 Invoker 暴露给服务消费者。这样一来,服务消费者只需通过这个 Invoker 进行远程调用即可,至于具体调用哪个服务提供者,以及调用失败后如何处理等问题,现在都交给集群模块去处理。

集群模块是服务提供者和服务消费者的中间层,为服务消费者屏蔽了服务提供者的情况,这样服务消费者就可以专心处理远程调用相关事宜。

对于容错方式官网上是这样的说的:

注意哦,官网说的是主要提供了这样几种,并没有完全列举,通过查看源码你可以看到:

org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker

有九个实现类,说明官方提供了九种容错方式供你选择:

而本文主要讨论的是:

org.apache.dubbo.rpc.cluster.support.FailfastClusterInvoker org.apache.dubbo.rpc.cluster.support.FailsafeClusterInvoker

搭建Demo项目

为了方便演示快速失败和失败安全在Dubbo中的体现,我们需要先搭建一个简单的Demo项目,搭建过程我就不演示了,这一小节仅对Demo的关键地方进行说明:

服务端接口如下:

服务端接口实现如下:

休眠3秒,模拟业务超时。

服务端Dubbo xml配置如下:

消费端Dubbo xml配置如下:

消费端在Test类中消费如下:

Dubbo中的快速失败

快速失败对应的实现类是:

org.apache.dubbo.rpc.cluster.support.FailfastClusterInvoker

启用该实现类,只需要在Dubbo xml中指定cluster属性为failfast:

先看一下实现类上的注释是怎么写的:

Execute exactly once, which means this policy will throw an exception immediately in case of an invocation error. Usually used for non-idempotent write operations。

FailfastClusterInvoker 只会进行一次调用,失败后立即抛出异常。适用于幂等操作,比如新增记录。

实现类的源码如下:

执行结果如下:

Dubbo中的失败安全

失败安全对应的实现类是:

org.apache.dubbo.rpc.cluster.support.FailsafeClusterInvoker

启用该实现类,只需要在Dubbo xml中指定cluster属性为failsafe:

先看一下实现类上的注释是怎么写的:

When invoke fails, log the error message and ignore this error by returning an empty Result. Usually used to write audit logs and other operations

FailsafeClusterInvoker 是一种失败安全的 Cluster Invoker。所谓的失败安全是指,当调用过程中出现异常时,FailsafeClusterInvoker 仅会打印异常,而不会抛出异常。适用于写入审计日志等操作。

实现类的源码如下:

执行效果如下,首先可以看到超时异常被捕获:

所以虽然超时了,但是在Test类中,还是打印出了returnStr:

文章背后的故事

本周输出这篇文章实属不易。

由于周六公司年会与运动会,我有幸当选了某队队长,所以本周周一到周五工作之外的时间都在忙碌着运动会的物质筹备、数据统计等相关工作。仅仅有早起的一小会空挡时间能随手翻翻书,但是写文章时间是不够的。

周六活动开始,从早上6点30分起床,到晚上23点做完最后的收尾工作,忙碌了整整一天。所幸的是我所在的小队在10支队伍中脱颖而出,勇夺第一。

在战况异常激烈的拔河环节,在所有拉拉队员整齐划一,嘶声呐喊的口号声中,参赛队员体现出的那种坚韧不拔、咬牙死撑的精神,深深的打动了我。一共有两次轮空的机会,我们队伍都与之擦肩而过,但是我们一次又一次的击败了实力强劲的对手,还是握住了总决赛拔河的绳子。由于对手轮空一轮,所以体力充沛,我们遗憾告负。但是在裁判没有吹哨之前,我们永不言弃。

所有项目比完之后,我所在队伍最终的总积分排名第一。在最终结果没有宣布之前,我们永不言弃。

周日,和我从小一起长大的表姐结婚,早上7点多去现场帮忙。中午吃饭时我都没敢喝太多酒,因为我想着这周的文章还没写,我得保持清醒。但是看到姐姐和姐夫站在大荧幕下的那一刻,我还是感动的热泪盈眶。下午陪家人玩了一下午。晚上到家之后已经非常疲倦了,但是我还是输出了这篇文章。

女朋友问我这周能不能不写,我想了一下说:不能。因为那一瞬间我想到了,路遥先生在《早晨从中午开始》中的一句话:只有初恋般的热情和宗教般的意志,人才有可能成就某种事业。

这也和年会中的一页PPT非常的符合:把你的全部,奉献给你热爱的一切。

我是一个普通的程序员,但是我热爱这个行业。

最后说一句

如果把Java集合的实现和Dubbo框架的实现分开来看,感觉这是两个不同的知识点,但是再往上抽离,可以发现它们都是快速失败机制与失败安全机制的实现方式。还是有着千丝万缕的联系。

还是之前说的,快速失败机制与失败安全机制,没有谁比谁好,只有结合场景而言,谁比谁更合适而已。

与本文相关的文章还有下面两篇,欢迎阅读:

《这道Java基础题真的有坑!我求求你,认真思考后再回答。》

《这道Java基础题真的有坑!我也没想到还有续集。》

才疏学浅,难免会有纰漏,如果你发现了错误的地方,还请你留言给我指出来,我对其加以修改。

如果你觉得文章还不错,你的转发、分享、赞赏、点赞、留言就是对我最大的鼓励。

感谢您的阅读,我坚持原创,十分欢迎并感谢您的关注。

以上。

欢迎关注公众号【why 技术】,坚持输出原创。愿你我共同进步。

https://juejin.im/post/5e1bf3b7f265da3e4b5be39a

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论