简单阐述一下自己对分布式事物的理解，如有错误欢迎指正：
刚性事物：即ACID这里不做过多解释，有不明白的同学建议快速掌握。
柔性事物：简单来说为运行过程不一致但最终保持一致。
一、产生原因：
分布式(微服务)系统中之间的跨库访问(例：商城项目中的会员数据库，订单数据库，支付数据库等、、、)与同一项目多数据源不同，使用于分布式系统后类似SOA接口之间调用时产生。
二、解决原理：
1）、CAP原理(即：一致性，可用性，分区容错性)
一致性：当系统对一个数据进行写操作时成功后，在查询则必须是改动后的值，当写操作失败也就必须查不多新值，在单机项目中又叫原子性。
可用性：服务可用性，就是说所有的读写请求在一定时间内要得到响应，不能一直等待下去。
分区容错性：指在分布式、微服务系统中，当 部分服务宕机后，其他核心服务能够不受影响能够继续提供服务。
2）、BAS理论：
采用CAP演化而来，是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一 致 性。主要有以下状态：
基本可用：在分布式系统出现故障时，允许损失部分可用性，保证核心可用，例如：一个服务正常响应时间为：2秒之内，在访问量大时可采用可对部分用户进行降级处理
软状态：允许系统存在中间状态，并且该状态不会允许系统整体可用性，即允许系统在不同的节点的副本在同步时候存在延迟。
最终一致性：指系统中的所有副本在经过一定时间后。最终能够达到一致的状态，最终一致性是弱一致性的特殊情况，BAS理论面向的是大型高可用分布式架构，通过牺牲强一致性来换去系统的可用性
3）、2PC原理：准备提交+确认提交
在分布式系统中一个事物可能会涉及多个服务，每个服务可以知道自己运行中该事物是否完成，但无法得知其他服务是否正常完成该事物，这个时候就需要引入一个第三 方协调框架进行统一管理(例：ZK,Redis等)第一阶段：收到各个服务的执行结果，第二阶段：根据各个服务的执行最终确认是否进行该事物的提交或者进行补偿
4）、3PC原理：
准备提交+预提交+确认提交
原理同2PC原理类似，这里就不做过多解释。
三、具体解决方案
LCN框架：
发起放：服务调用者
参与方：被调用者
这是该框架中2个最为重要的角色请大家用时务必理解
事物分组：多个单机事物放到同一事物进行管理，形成事物ID，当发起方执行时会向事物协调者(zk)发送一个事物分组并且在调用参与方的同时将该分钟的id以请求参数的方式发送给参与方，参与收到这样的请求后执行代码但不提交事物，当执行结束后会将执行结果返回给事物协调者，事物协调根据各个事物返回的结果确认该事物是否提交并将结果返回给各个服务。
四、其他解决方案还有：
MQ，提供补偿 接口，GTC。。。。。
自述：本人为一名普通java程序员欢迎各位同仁，前辈进行批评，指正。内容未排版因为我要睡觉，赠程序员苦逼的一天。
原文：https://www.cnblogs.com/shijunyong/p/11901943.html