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