事物特性(ACID)
原子性（A）
所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。
一致性（C）
事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。
隔离性（I）
所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
持久性（D）
所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。
这种特性 简称 刚性事物
分布式事物分布式事物产生原因
分布式事物产生的原因
分布式事务产生的场景
在分布式系统，都会垂直拆分数据库，分为支付数据库、订单数据库、积分数据库、优惠全数据库等，业务组成，分为多个数据源，会产生分布式事物问题。
spring事务和分布式事务的区别是什么?
spring事务，本地事务
分布式事务是跨服务间的通讯（不同的数据库连接）
分布式理论知识
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)：在网络分区的情况下，被分隔的节点仍能正常对外服务
Base理论
BASE理论是指，Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）。是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。
1、基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务，等。
2、软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
3、最终一致性：
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计，追求强一致性模型。
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
柔性事务和刚性事务
柔性事务满足BASE理论（基本可用，最终一致）
刚性事务满足ACID理论
本文主要围绕分布式事务当中的柔性事务的处理方式进行讨论。
柔性事务分为
两阶段型
补偿型
异步确保型
最大努力通知型几种。 由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。
什么是XA接口
XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：
什么是Jta
作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种：
1.J2EE容器所提供的JTA实现(JBoss)
2.独立的JTA实现:如JOTM，Atomikos.这些实现可以应用在那些不使用J2EE应用服务器的环境里用以提供分布事事务保证。如Tomcat,Jetty以及普通的java应用。
基于XA协议的两阶段（2PC）提交
所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。
XA一般由两阶段完成，称为two-phase commit(2PC)。
阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager汇报自己已经准备好。
阶段二为提交阶段。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
如下图所示：
XA的性能问题
XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。
只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。
分布式事物解决方案
分布式事物问题，在互联网公司比较常见，例如“”分布式事物解决方案 可以使用全局事物2pc（两段提交协议）、3pc(三段提交协议)，消息中间件、tcc、gts、提供回滚接口、分布式数据库
2PC和3PC区别：https://blog.csdn.net/Michaelwubo/article/details/81482931
LCN 核心采用3PC+TCC补偿机制
使用LCN框架解决分布式事务
什么是LCN框架
LCN分布式事务框架v4.0 https://www.txlcn.org
"LCN并不生产事务，LCN只是本地事务的搬运工"
框架特点
兼容SpringCloud、Dubbo
使用简单，低依赖，代码完全开源
基于切面的强一致性事务框架
高可用，模块可以依赖Dubbo或SpringCloud的集群方式做集群化，TxManager也可以做集群化
支持本地事务和分布式事务共存
事务补偿机制，服务故障或挂机再启动时可恢复事务
LCN框架原理
参考网站 https://github.com/codingapi/tx-lcn/wiki/LCN%E5%8E%9F%E7%90%86
lcn框架原理
核心步骤
创建事务组 是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。
添加事务组 添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息添加通知给TxManager的操作。
关闭事务组 是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager的动作。当执行完关闭事务组的方法以后，TxManager将根据事务组信息来通知相应的参与模块提交或回滚事务。
