前言：最近，在家里养伤，由于博主骑自行车不小心摔跤了，给自己造成了影响，同时也给公司造成了影响，没有按时报到。希望大家骑自行车时一定要小心，手里不要拿手机，还是那句话：道路千万条，安全第一条，行车不规范，亲人两行泪。好了，这是血的教训。今天的主题不是教如何骑自行车，哈哈哈。言归正传，利用在家养伤总结一下面试中经常问到的在微服务架构中如何解决分布式事务的问题。因为，这个问题，当时回答的不是太好，下来也查询很多资料，算是总结一下学习的心得，如果有不对的地方还请大佬们能多多指点。
一、理论首先这个问题是出现在微服务架构、分布式环境中的，在单机系统中是不用考虑这个问题的，首先我们来看下分布式系统的CAP原则和BASE理论。
我们知道，这个三个特征最多只能满足两个，三者不可兼得。一致性：所有节点在同一时间点所有的数据都是一致的。可用性：在任何时候分布式系统总是可以成功读和写。分区容忍性：在某些节点因为网络故障时，仍然能够满足一致性和可用性的服务。
选择CA：放弃p 等同于放弃分布式系统，只存在于单机系统
选择CP：也就是选择分区容忍性和强一致性，允许在极端情况下出现暂时服务的不可用。
选择AP：允许出现数据的短时不一致，在服务注册的场景短期的数据不一致，不会对服务造成影响。因此采用AP原则的注册中心才是微服务比较合适的选择。
然后，介绍一下BASE理论，如图底部的词汇，BASE指Basically Available 基本可用，Soft-state 软状态（状态允许有短时间不同步，异步）， Eventual Consistency 最终一致性，它是对CAP中一致性和可用性的权衡的结果，BASE的核心思想是即使无法做到强一致性，也可以根据系统特性，采用适当的方式达到最终一致性。基于这样的理论知识，我们只要做到最终一致性就可以解决分布式系统中的问题了。在分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。
如果感觉还是不太明白建议参考CAP框架作者的这篇文章：https://www.cnblogs.com/savorboard/p/base-an-acid-alternative.html
二、场景一图胜千言：
解决方案：
（1）刚性事务
全局事务（标准的分布式事务）
优点：严格的ACID；
缺点：效率非常低（微服务架构下已经不太合适）
原因：1）全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（2pc）与资源层（如数据库进行交互）。使用全局事务，数据被lock的时间跨整个事务，直到全局事务结束。
2）2pc是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束，这样当业务规模越来越大的情况下，2pc的局限性就越来越明显，系统可伸缩性就会变的很差。
3）与本地事务相比，XA协议的系统开销相当大，因而应当谨慎考虑是否确实需要分布式事务。而且只有支持XA协议的资源才能参与分布式事务。
（2）柔性事务
可靠消息最终一致性（异步确保型）
TCC（两阶段型、补偿型）【略】
最大努力通知（非可靠消息、定期校对）【略】
我们现在知道有这么多解决分布式事务的方案，我们能否自己去实现一个分布式事务框架呢？假如我们选择柔性事务中的，可靠消息最终一致（异步确保型）这种方案来实现就不得不涉及到消息中间件的使用了，消息中间价在分布式系统中的主要作用是，异步通讯、解耦、削峰填谷等。如下图所示：