关于后端:布式系统消息异常该何去何从

5次阅读

共计 1340 个字符，预计需要花费 4 分钟才能阅读完成。

一旦谈到分布式，微服务等这些具备很高逼格的代名词，总能让你在面试中怀才不遇，不是因为这些词的英文翻译的好，而是古代互联网乃至企业级开发的确在分布式，微服务等模式下获得了良好的架构成果。无论是微服务，还是之前的 SOA，总是离不开异步解决模型，小到程序中 IO 的解决，大到零碎间的音讯交互，处处都有异步的身影。

谈到零碎之间的音讯异步解决，就不能不谈音讯队列（MQ），目前业界比拟风行的 MQ 类型请自行百度脑补。然而须要揭示一下，MQ 只是实现数据异步解决的一种解决方案，没有 MQ 能不能实现异步解决呢？当然能，最简略粗犷的莫过于采纳数据库形式，音讯生产者间接把数据插入数据库，消费者采纳读取数据库的形式来获取数据，所以 MQ 并不等于异步解决哦。

异步音讯解决最大水平上解耦了各个系统，为每个零碎独立扩大提供了更大空间，然而异步音讯解决也同时面临着一些挑战，比方：音讯管道性能，音讯管道的高可用等，其中最贴近业务层的可能非“数据异样解决”莫属，基本上可认为这是数据处理模型的最末端，数据流向的尾部，但往往却是业务中比拟重要的局部。

如果一条异步音讯作为一个分布式事务中的一环，那还设计到音讯处理结果的反馈，分布式协调器会依据音讯后果的胜利与否来决定的事务的后果。

单就异步音讯生产端来讲，依据不同的业务场景就有以下几种异样解决计划

这是所有异样数据处理计划中最粗犷，同时也是最简略的一种：产生异样的时候，间接疏忽，什么都不做。

面对异样不采取任何措施，乍一听这可能是个很蹩脚的计划，然而在理论业务中，这可能是齐全能够承受的。如果因为谬误导致的损失很小，甚至能够疏忽，然而建设一套谬误纠正机制的老本远远高于疏忽异样，这种场景下抉择间接疏忽往往是一种更优的计划。而且当谬误纠正机制设计到须要人工染指操作的时候，代价会更高，而且还会引入影响其余业务的可能，更为可怕的是如果谬误纠正机制自身呈现问题，那代价更是 …..

举个很简略的栗子：像一些登录日志的统计操作，如果解决某个人登录的数据出现异常，往往会抉择间接疏忽。因为统计这种业务自身就带有数据的容错机制，100000 和 100001 在统计需要看来没有什么区别。

当间接疏忽的计划不可行的时候，你可能须要重试的操作。如果在重试的状况下有足够高的成功率，那重试就是正当的抉择。重试尽管能够改过间接性的谬误，然而它对那些违反业务规定，违反数据模型的数据无能为力。

在最现实的状况下，如果重试操作是幂等性的，什么叫幂等性能（本人去百度吧）？事件就会简略很多，重试操作能够放心大胆的去施行。然而在重试操作通过一段时间或者肯定次数之后还未胜利的话，少数状况下可能须要有肯定的后续策略，比方：重试 10 次之后如果还是失败，则放弃。

这个策略是分布式事务中常常用到的，与其说是弥补，不如说是回滚操作。特地是在程序接管到数据会有一系列的操作的情景下，弥补操作相似于事务回滚的概念，让零碎回到产生这一系列操作之前的状态。这种弥补的机制非常适合于那种有“事务”需要的场景。

你的业务中有哪些“事务”的需要场景呢？欢送在留言中体现，另外再略微提一下，每周送架构书籍的流动依然在进行哦，欢送关注