分布式事务解决方案
1.分布式事务产生的原因
来源于微服务、分布式系统之间跨数据库产生的问题，数据库做垂直分割(按照业务需求划分数据库、分库)，分为多个不同的数据源(JDBC连接)，会产生分布式事务的问题。
在微服务环境下，因为会根据不同的业务会拆分成不同的服务，比如会员服务、订单服务、商品服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。
服务与服务之间通讯采用RPC远程调用技术，但是每个服务中都有自己独立的数据源，即自己独立的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务产生的原因。
2.分布式事务产生的场景
订单服务、库存服务。服务之间的调用接口的时候会产生分布式事务的问题，服务之间的调用走的是http协议进行通讯的。
流程图：
3.Spring事务和分布式事务的区别？
Spring事务是本地事务。
分布式事务是需要跨服务进行通讯的。
4.如何区分分布式事务
不同的JDBC连接,下图是一个分布式事务场景。虽然二个服务连接的是同一个数据库，但是它们有各自的JDBC连接，所以属于分布式事务。
5.分布式事务解决方案
5.1 使用Jta+Automatic 只适合传统项目。
5.2 消息中间件MQ，底层通过Base理论 柔性事务解决
5.3 2PC(二段提交协议)、3PC
5.4 TCC补偿、GTS 属于阿里产品
5.5 TX-LCN框架
5.6 支付回调方式(重试机制+补偿机制)
核心原理：LCN并不生产事务，LCN只是本地事务的协调工。
LCN官网：http://www.txlcn.org/zh-cn/
6.基本的事务概念
原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)，ACID原则，这种特性也成 刚性事务。
博客：https://www.cnblogs.com/ming-blogs/p/10513874.html
7.base理论
BASE理论是指，Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）。是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。
1、基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务，等。
2、软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
3、最终一致性：
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计，追求强一致性模型。
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
软状态、最终一致性，对接支付宝项目。
支付宝流程回调：同步回调地址、异步回调地址。
8.CPA理论
CAP由Eric Brewer在2000年PODC会议上提出[1][2]，是Eric Brewer在Inktomi[3]期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想：
• 数据一致性(consistency)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency)[5]
• 服务可用性(availability)：所有读写请求在一定时间内得到响应，可终止、不会一直等待
• 分区容错性(partition-tolerance)：在网络分区的情况下，被分隔的节点仍能正常对外服务
9.柔性事务与刚性事务
柔性事务满足Base理论(基本可用、最终一致性)、CAP理论。
刚性事务满足ACID理论。
柔性事务分为：
9.1.二阶段型
9.2补偿型
9.3异步确保型
9.4最大努力通知型
10.LCN分布式事务原理
LCN并不生产事务，LCN只是本地事务的协调工。
事务协调者、本地服务(订单服务(发起方)、库存服务(参与方))。
发起方：调用其他服务接口。
参与方：被别人调用的接口。
执行流程：
1.LCN客户端（发起方和参与方都必须要注册到事务协调者中） 建立一个长连接。解答：长连接 好处减少宽带传输 弊端比较占内存。
2.订单服务（发起方）调用库存服务接口（参与方）之前会向TxManager事务协调者创建一个事务的分组id。
3.订单服务（发起方）调用库存服务接口（参与方）的时候，会在请求头中存放该事务的分组id，给库存服务。
4.如果库存服务获取到请求头中有对应的事务分组id，库存服务业务逻辑代码执行完毕的，会采用假关闭，不会提交该事务。
5.参与方在什么时候提交事务？
答案：肯定在发起方 执行成功情况下。
订单服务（发起方）调用库存服务接口（参与方）之后，如果订单服务（发起方）执行没有问题的情况下。
订单服务（发起方）使用对应的事务分组id，通知给TxManager事务协调者，让后TxManager事务协调者在根据该事务分组id，通知给所有的参与方提交事务。
集成LCN分布式事务注意事项
版本集成问题: 目前LCN版本已经升级为4.0了，但是官方没有SpringCloud2.0的demo案例。因为LCN本身是开源的，网上有大牛对LCN框架源码做修改，可以支持SpringCloud2.0版本。 使用LCN官方提供的@TxTransaction注解解决分布式事务难题，isStart参数是否LCN事务发起方 true 是:是发起方 false 否:是参与方。
LCN 官网：http://www.txlcn.org/zh-cn/
github地址：https://github.com/codingapi/tx-lcn
博客内容来源：http://www.mayikt.com/
