写点什么

布式系统消息异常该何去何从

发布于: 2020 年 09 月 13 日
布式系统消息异常该何去何从


异步处理模型


一旦谈到分布式,微服务等这些具有很高逼格的代名词,总能让你在面试中脱颖而出,不是因为这些词的英文翻译的好,而是现代互联网乃至企业级开发确实在分布式,微服务等模式下取得了良好的架构效果。无论是微服务,还是之前的 SOA,总是离不开异步处理模型,小到程序中 IO 的处理,大到系统间的消息交互,处处都有异步的身影。


谈到系统之间的消息异步处理,就不能不谈消息队列(MQ),目前业界比较流行的 MQ 类型请自行百度脑补。但是需要提醒一下,MQ 只是实现数据异步处理的一种解决方案,没有 MQ 能不能实现异步处理呢?当然能,最简单粗暴的莫过于采用数据库方式,消息生产者直接把数据插入数据库,消费者采用读取数据库的方式来获取数据,所以 MQ 并不等于异步处理哦。


异步消息处理最大程度上解耦了各个系统,为每个系统独立扩展提供了更大空间,但是异步消息处理也同时面临着一些挑战,比如:消息管道性能,消息管道的高可用等,其中最贴近业务层的可能非“数据异常处理”莫属,基本上可认为这是数据处理模型的最末端,数据流向的尾部,但往往却是业务中比较重要的部分。


如果一条异步消息作为一个分布式事务中的一环,那还设计到消息处理结果的反馈,分布式协调器会根据消息结果的成功与否来决定的事务的结果。


单就异步消息消费端来讲,根据不同的业务场景就有以下几种异常处理方案

直接忽略


这是所有异常数据处理方案中最粗暴,同时也是最简单的一种:发生异常的时候,直接忽略,什么都不做。


面对异常不采取任何措施,乍一听这可能是个很糟糕的方案,但是在实际业务中,这可能是完全可以接受的。如果因为错误导致的损失很小,甚至可以忽略,但是建立一套错误纠正机制的成本远远高于忽略异常,这种场景下选择直接忽略往往是一种更优的方案。而且当错误纠正机制设计到需要人工介入操作的时候,代价会更高,而且还会引入影响其他业务的可能,更为可怕的是如果错误纠正机制本身出现问题,那代价更是.....


举个很简单的栗子:像一些登录日志的统计操作,如果处理某个人登录的数据出现异常,往往会选择直接忽略。因为统计这种业务本身就带有数据的容错机制,100000 和 100001 在统计需求看来没有什么区别。

重试


当直接忽略的方案不可行的时候,你可能需要重试的操作。如果在重试的情况下有足够高的成功率,那重试就是合理的选择。重试虽然可以改正间接性的错误,但是它对那些违反业务规则,违反数据模型的数据无能为力。


在最理想的情况下,如果重试操作是幂等性的,什么叫幂等性能(自己去百度吧)?事情就会简单很多,重试操作可以放心大胆的去实施。但是在重试操作经过一段时间或者一定次数之后还未成功的话,多数情况下可能需要有一定的后续策略,比如:重试 10 次之后如果还是失败,则放弃。

补偿


这个策略是分布式事务中经常用到的,与其说是补偿,不如说是回滚操作。特别是在程序接收到数据会有一系列的操作的情景下,补偿操作类似于事务回滚的概念,让系统回到发生这一系列操作之前的状态。这种补偿的机制非常适合于那种有“事务”需求的场景。


你的业务中有哪些“事务”的需求场景呢?欢迎在留言中体现,另外再稍微提一下,每周送架构书籍的活动仍然在进行哦,欢迎关注



更多精彩文章


发布于: 2020 年 09 月 13 日阅读数: 105
用户头像

一个坚持把架构做到极致的技术人 2014.10.19 加入

还未添加个人简介

评论

发布
暂无评论
布式系统消息异常该何去何从