Introduction: Recently, at home and recuperate, because the bloggers do not care cycling wrestling, give yourself had an impact, but also had an impact on the company, did not register on time. I hope you must be careful when riding a bike, do not take the hands of the phone, then again: Road 10 million, safety first, driving non-standard, two lines of relatives of tears. Well, this is the lesson of blood. Today's topic is not taught how to ride a bike, ha ha ha. Closer to home, use at home and recuperate summarize how to solve the problem of distributed transactions in micro-service architecture interview frequently asked. Because of this problem, then the answer is not very good, down to also check a lot of information, summed up the experience of learning about, if there is something wrong bigwigs can also ask a lot of guidance.
First, the theoretical
First, the problem is in the micro-service architecture, distributed environment, in a stand-alone system is not to consider this question, we first look at BASE CAP principles and theory of distributed systems.
We know that this can only meet three features up to two, three can not have both. Consistency: All nodes in the same point in time all the data are consistent. Availability: At any time distributed system always can be successfully read and write. Partition tolerance: in some nodes because of network failure, still be able to meet the consistency and availability of services.
Select CA: p is equivalent to give up give up a distributed system, exists only in stand-alone system
selection CP: that is, choose partition tolerance and strong consistency, allowing a temporary service is not available in extreme cases.
Select AP: allows short data inconsistency, inconsistent scenes registered in the short-term service data, will not affect the service. Therefore, the use of AP principle of micro registry service is more appropriate choice.
Then, introduce BASE theory, shown at the bottom of the vocabulary, the basic Basically Available BASE means available, Soft-state soft-state (the state not allowing a short time synchronous, asynchronous), Eventual Consistency final consistency, it is CAP Consistency and the results of usability tradeoffs, the core idea is that even if BASE can not do strong consistency, also be based on system characteristics, appropriate way to achieve eventual consistency. Based on this theoretical knowledge, as long as we do the final consistency problem can be solved in a distributed system. In a distributed system, the most important thing is to meet business needs, rather than the pursuit of abstract, absolute system characteristics.
If you feel or do not understand the proposed reference framework of the CAP this article: https://www.cnblogs.com/savorboard/p/base-an-acid-alternative.html
Two, Scene
A picture is worth a thousand words:
Third, the solution analysis
solution:
(1) rigid Affairs
Global transaction (standard distributed transaction)
Pros: Strict ACID;
Disadvantages: the efficiency is very low (under micro-architecture have been less appropriate service)
Reasons: 1) the global transaction mode, the global transaction manager (TM) commit protocol (2PC) and resource layer (e.g., interacting with the database) by using the two XA interface stage. Use global transactions, data lock time across the entire transaction until the end of the global transaction.
2) 2pc anti scalable model, transaction processing, participants need to have the resources to hold until the end of the entire distributed transaction, so that when the increasing scale of business situations, the more and more obvious limitations 2pc , scalability of the system will become poor.
3) Compared with the local transaction, XA protocol overhead is considerable and should therefore carefully consider whether really need a distributed transaction. And only supports the XA protocol resources to participate in distributed transactions.
(2) Flexible affairs
Reliable sources eventual consistency (asynchronous ensure that type)
TCC (two-stage type, compensation type) [omitted]
Best efforts to notify (non-reliable sources, regularly proofread) [omitted]
我们现在知道有这么多解决分布式事务的方案，我们能否自己去实现一个分布式事务框架呢？假如我们选择柔性事务中的，可靠消息最终一致（异步确保型）这种方案来实现就不得不涉及到消息中间件的使用了，消息中间价在分布式系统中的主要作用是，异步通讯、解耦、削峰填谷等。如下图所示：
如果按照上面的图，大家可能认为它很简单呀，一个发送消息，一个接受消息。但是在分布式系统中，需要通过网络进行通信的，就引入了数据传输的不确定性，也就是CAP理论中的P（分区容错性的问题），如下图所示：
很显然，正是因为跨网络，就会产生消息发送不一致的问题，也就是说，如果我的业务操作成功，那么有这个业务操作所产生的消息一定要成功投递出去，否则就丢失消息。那么我们该怎么解决这样的问题呢？
也就是如何保障消息发送一致性？通常我们在使用消息队列来处理业务都会遇到这样的场景：
public void CompleteOrder() { //订单处理 orderService.OrderProcess(); //财务处理（发送消息） ...... }
（1）如果业务操作成功，执行消息发送前应用故障，消息发送不去去，导致消息丢失（订单系统和财务系统数据产生不一致）
（2）如果业务操作成功，应用正常，但消息系统故障或者网络故障，也会导致消息发送不出去（订单系统和财务系统数据产生不一致）。
另外一种处理方案：
public void CompleteOrder() { //财务处理（发送消息） ...... //订单处理 orderService.OrderProcess(); }
也就是，我先发送消息再处理订单，这种做法更不可控了，消息发送出去了，但是订单处理失败了（导致订单和财务系统数据的不一致），记住在处理这种场景，一定是业务数据先入库，再发送消息的。
貌似这两种方式都不能保证业务数据的一致性，当然，我们可以借助JMS标准中的XA协议方式来保证消息发送的一致性，但是这种方式引入了XA，违背了柔性事务的初衷，会带来很多局限性：
（1）要求业务操作的资源（也就是数据库）必须支持XA协议（并不是所有的数据库都支持XA）
（2）两阶段提交协议的成本
（3）持久化成本等DTP模型的局限性（全局锁、成本高、性能低）
另外一种变通的做法如下：（这种方案只是解决的业务处理成功，消息一定能发送到消息中间件中）
问题：
（1）上面的消息发送一致性方案的正向流程是可行的，但是如果遇到异常流程该怎么处理？
（2）消息发送到消息中间件能得到保障，但是消息的准确消费又如何保障呢？
（3）有没有支持这种发送一致性流程的现成消息中间件？
先来聊聊问题（1），有哪些场景会出现异常，如下图所示：
从主动应用方（生产者）来分析：
（1）预发消息失败，消息未进行存储，业务操作未执行（可能的原因：主动方应用、网络、消息中间件、消息存储等），这种场景不会出现不一致性。
（2）预发送消息后，主动方应用没有收到返回消息存储结果，可能的状态有：消息未进行存储，业务操作未执行（不会出现不一致性）；如果消息已进行存储【待确认】，业务操作未执行，会出现不一致性。
（3）收到消息存储成功的返回结果，但未执行业务操作就失败，可能的状态有：消息已进行存储【待确认】，业务操作未执行，会出现不一致性的问题。
从消息中间件的角度分析：
（1）消息中间件没有收到主动方应用的业务操作处理结果，可能的状态：消息已经存储（待确认），业务操作未执行（或者业务操作出错回滚了），会出现数据的不一致性问题;如果消息已经存储（待确认），业务操作成功，也会出现数据的不一致性。
（2）消息中间件收到业务操作结果（成功/失败），但处理消息存储中的消息状态失败，可能的状态：消息已经存储（待确认），业务操作未执行（或业务操作出错回滚了），会出现数据的不一致性问题；如果消息已经存储（待确认），业务操作成功，也会出现数据的不一致性问题。
那我们该如何处理这样的异常问题呢？如下图所示：
这样就可以处理异常的流程，有人可能会说，异常处理流程也可能发生异常呀，其实大家认真看的话，异常处理基本上都是查询，如果查询出现了异常，定时补救也是可以的。
总结：关于上面异常处理总结
（1）消息未进存储，业务操作未执行，不会出现一致性问题。
（2）消息已进行存储（待确认），业务操作未执行，会出现一致性问题，异常处理手段，确认业务操作结果，处理消息【删除消息】
（3）消息已进行存储（待确认），业务操作成功，会出现一致性问题，异常处理手段，确认业务操作结果，处理消息【更新消息状态，执行消息投递】
对于问题（3）有没有现成的消息中间件支持消息发送一致性，答案是：没有。是因为常用的MQ队列消息的处理流程无法实现消息发送一致性，因此直接使用现成的MQ中间件产品无法实现可靠消息最终一致性的分布式解决方案。
对于问题（2）消息发送到消息中间件能得到保障，但是消息的准确消费又如何保障呢？
以前的流程，如下图所示：
红框圈住的就是消息的消费流程，在这个流程中，任何一个环节都有可能出问题具体到下面这张图：
那我们如何处理，这些异常呢？处理的方法有很多，这里列出常规的做法：对于未确认的消息，采用按照规则重新投递的方式进行处理。这里就不介绍了， 当然，我们需要处理极端情况：消息重发也得有次数限制，要不然就变成了死循环，对于超过重发次数的消息，进入到死信队列，等待人工干预或者延后定期处理。同时也需要处理被动方在处理业务时要实现幂等操作。
四、总结
好了，暂时分享到这里吧，虽然在分布式系统中已经有现成的框架，比如.net core 中的 CAP框架，非常的不错，我们生产环境中已经用了很长时间，框架能帮助我们解决实际场景下的问题，但是我们也要明白框架背后的原理，明白大概的原理，再去看CAP的源码，你会恍然大悟的！哈哈哈哈。
参考资料：
龙果学院 吴水成老师 《微服务架构的分布式事务解决方案》 https://www.roncoo.com/details/7ae3d7eddc4742f78b0548aa8bd9ccdb
CAP框架作者 杨老师 https://www.cnblogs.com/savorboard/p/base-an-acid-alternative.html
作者：郭峥
出处：http://www.cnblogs.com/runningsmallguo/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。