菜菜哥，如今北京疫情这么厉害，出京到外地都会被排斥呢程序员
因此呀，你应该老实的呆在北京，不要给国家添乱web
为了给国家少些负担，昨天我去作了核酸检测，那人多人，排好长的队面试
新冠疫情，人人有责嘛数据库
你猜怎么着，这种排队和程序中的消息队列好像微信
同窗，你果真骨骼惊奇，是块程序员的料cookie
这让我想到分布式系统中，那些消息队列的数据处理，消费者若是处理消息异常了怎么办呢？session
那就要看具体场景具体需求了，不过多数状况下也不外乎如下几种情形架构
一旦谈到分布式，微服务等这些具备很高逼格的代名词，总能让你在面试中脱颖而出，不是由于这些词的英文翻译的好，而是现代互联网乃至企业级开发确实在分布式，微服务等模式下取得了良好的架构效果。不管是微服务，仍是以前的SOA，老是离不开异步处理模型，小到程序中IO的处理，大到系统间的消息交互，到处都有异步的身影。并发
谈到系统之间的消息异步处理，就不能不谈消息队列（MQ），目前业界比较流行的MQ类型请自行百度脑补。可是须要提醒一下，MQ只是实现数据异步处理的一种解决方案，没有MQ能不能实现异步处理呢？固然能，最简单粗暴的莫过于采用数据库方式，消息生产者直接把数据插入数据库，消费者采用读取数据库的方式来获取数据，因此MQ并不等于异步处理哦。app
异步消息处理最大程度上解耦了各个系统，为每一个系统独立扩展提供了更大空间，可是异步消息处理也同时面临着一些挑战，好比：消息管道性能，消息管道的高可用等，其中最贴近业务层的可能非“数据异常处理”莫属，基本上可认为这是数据处理模型的最末端，数据流向的尾部，但每每倒是业务中比较重要的部分。
若是一条异步消息做为一个分布式事务中的一环，那还设计到消息处理结果的反馈，分布式协调器会根据消息结果的成功与否来决定的事务的结果。
单就异步消息消费端来说，根据不一样的业务场景就有如下几种异常处理方案
这是全部异常数据处理方案中最粗暴，同时也是最简单的一种：发生异常的时候，直接忽略，什么都不作。
面对异常不采起任何措施，乍一听这多是个很糟糕的方案，可是在实际业务中，这多是彻底能够接受的。若是由于错误致使的损失很小，甚至能够忽略，可是创建一套错误纠正机制的成本远远高于忽略异常，这种场景下选择直接忽略每每是一种更优的方案。并且当错误纠正机制设计到须要人工介入操做的时候，代价会更高，并且还会引入影响其余业务的可能，更为可怕的是若是错误纠正机制自己出现问题，那代价更是.....
举个很简单的栗子：像一些登陆日志的统计操做，若是处理某我的登陆的数据出现异常，每每会选择直接忽略。由于统计这种业务自己就带有数据的容错机制，100000和100001在统计需求看来没有什么区别。
当直接忽略的方案不可行的时候，你可能须要重试的操做。若是在重试的状况下有足够高的成功率，那重试就是合理的选择。重试虽然能够改正间接性的错误，可是它对那些违反业务规则，违反数据模型的数据无能为力。
在最理想的状况下，若是重试操做是幂等性的，什么叫幂等性能（本身去百度吧）？事情就会简单不少，重试操做能够放心大胆的去实施。可是在重试操做通过一段时间或者必定次数以后还未成功的话，多数状况下可能须要有必定的后续策略，好比：重试10次以后若是仍是失败，则放弃。
这个策略是分布式事务中常常用到的，与其说是补偿，不如说是回滚操做。特别是在程序接收到数据会有一系列的操做的情景下，补偿操做相似于事务回滚的概念，让系统回到发生这一系列操做以前的状态。这种补偿的机制很是适合于那种有“事务”需求的场景。
你的业务中有哪些“事务”的需求场景呢？欢迎在留言中体现，另外再稍微提一下，每周送架构书籍的活动仍然在进行哦，欢迎关注
那我核酸检测的结果，会不会直接采用忽略的策略呀，让人担忧
不用担忧，这应该是一个事务性的操做，检测结果确定会通知你的，由于你掏钱了....
本文分享自微信公众号 - dotNET跨平台（opendotnet）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。