异步处理模型
一旦谈到分布式，微服务等这些具有很高逼格的代名词，总能让你在面试中脱颖而出，不是因为这些词的英文翻译的好，而是现代互联网乃至企业级开发确实在分布式，微服务等模式下取得了良好的架构效果。无论是微服务，还是之前的SOA，总是离不开异步处理模型，小到程序中IO的处理，大到系统间的消息交互，处处都有异步的身影。
谈到系统之间的消息异步处理，就不能不谈消息队列（MQ），目前业界比较流行的MQ类型请自行百度脑补。但是需要提醒一下，MQ只是实现数据异步处理的一种解决方案，没有MQ能不能实现异步处理呢？当然能，最简单粗暴的莫过于采用数据库方式，消息生产者直接把数据插入数据库，消费者采用读取数据库的方式来获取数据，所以MQ并不等于异步处理哦。
异步消息处理最大程度上解耦了各个系统，为每个系统独立扩展提供了更大空间，但是异步消息处理也同时面临着一些挑战，比如：消息管道性能，消息管道的高可用等，其中最贴近业务层的可能非“数据异常处理”莫属，基本上可认为这是数据处理模型的最末端，数据流向的尾部，但往往却是业务中比较重要的部分。
如果一条异步消息作为一个分布式事务中的一环，那还设计到消息处理结果的反馈，分布式协调器会根据消息结果的成功与否来决定的事务的结果。
单就异步消息消费端来讲，根据不同的业务场景就有以下几种异常处理方案
直接忽略
这是所有异常数据处理方案中最粗暴，同时也是最简单的一种：发生异常的时候，直接忽略，什么都不做。
面对异常不采取任何措施，乍一听这可能是个很糟糕的方案，但是在实际业务中，这可能是完全可以接受的。如果因为错误导致的损失很小，甚至可以忽略，但是建立一套错误纠正机制的成本远远高于忽略异常，这种场景下选择直接忽略往往是一种更优的方案。而且当错误纠正机制设计到需要人工介入操作的时候，代价会更高，而且还会引入影响其他业务的可能，更为可怕的是如果错误纠正机制本身出现问题，那代价更是.....
举个很简单的栗子：像一些登录日志的统计操作，如果处理某个人登录的数据出现异常，往往会选择直接忽略。因为统计这种业务本身就带有数据的容错机制，100000和100001在统计需求看来没有什么区别。
重试
当直接忽略的方案不可行的时候，你可能需要重试的操作。如果在重试的情况下有足够高的成功率，那重试就是合理的选择。重试虽然可以改正间接性的错误，但是它对那些违反业务规则，违反数据模型的数据无能为力。
在最理想的情况下，如果重试操作是幂等性的，什么叫幂等性能（自己去百度吧）？事情就会简单很多，重试操作可以放心大胆的去实施。但是在重试操作经过一段时间或者一定次数之后还未成功的话，多数情况下可能需要有一定的后续策略，比如：重试10次之后如果还是失败，则放弃。
补偿
这个策略是分布式事务中经常用到的，与其说是补偿，不如说是回滚操作。特别是在程序接收到数据会有一系列的操作的情景下，补偿操作类似于事务回滚的概念，让系统回到发生这一系列操作之前的状态。这种补偿的机制非常适合于那种有“事务”需求的场景。
你的业务中有哪些“事务”的需求场景呢？欢迎在留言中体现，另外再稍微提一下，每周送架构书籍的活动仍然在进行哦，欢迎关注
