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

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

异步处理模型

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

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

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

如果一条异步消息作为一个分布式事务中的一环,那还设计到消息处理结果的反馈,分布式协调器会根据消o 4 0 p 0 z K u c息结果的成功与否来决定的R ! ! }事务的结$ 7 s * J 9 D /果。

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

直接忽略

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

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

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

v ) Y (

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

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

补偿

这个策略是分布式事务中经常用到的,与其说是补偿,不如说是回滚操[ 2 V ^ 5 ?作。特别是在程序接收到数据会有一系列的m B 6 j - V操作的情景下,补偿[ % e x _ u d ]操作类似于事务回滚的概念,让系 o 0 r ) p统回到发生这一系列操作之前的状态。这种补偿的机制非常适合于那种有“事务”需求的场景。

你的业务中有哪些“事务”的需求场景呢?欢迎在留言中体现,另外再稍微提一下,每周送架构书籍的活I q O 5 q W . @动仍然在进行哦,N t $ g _ = $ 5欢迎关注

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

更多精彩文章

  • 分布式大并发系列
  • 架构设计系列
  • 趣学算法和数据结构系列
  • 设计模式系列

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