什么是事务？
事务：数据库执行的一个逻辑单位，由一个数据库操作数列（多个业务逻辑）构成
事务的四个特性
事务拥有以下四个特性，习惯上被称为ACID特性：
原子性(Atomicity)：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性(Consistency)：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
隔离性(Isolation)：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
持久性(Durability)：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。
什么是分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性
分布式事务CAP定理
C: 数据一致性
A: 可用性（每个服务都可用）
P: 网络分区容错性,每个服务不在一个网络内，服务仍然可用
CAP三种不能共存，选择了CA（分布式不用） 而放弃了 P，为了保证数据一致性从而拒绝网络连接；对于 CP（ZooKeeper） 来说，放弃可用性，追求一致性和分区容错性， 其实就是追求的强一致；对于 AP（eureka） 来说， 放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，选择了CP并不是只要C、P，而是相对于前两者来说，A权重比较小，C、A是必须保证的。
分布式事务解决方案
2PC两段式事务
涉及角色：
事务协调者：负责协调多个参与者进行事务投票及提交(回滚)
事务参与者：事务的执行者 优缺点：保证强一致性，但是牺牲了可用性，对性能影响较大。
TCC柔性补偿（代码补偿）事务
TCC（Try Confirm Cancel）是由三部分组成，根据上图的流程，当业务应用执行的时候，TCC会调用Try接口，提交事务，然后检测Try有没有异常的。
如果没有异常-->调用Confirm一个一个确认。
有异常-->调用Cancel接口补偿业务，举例子：库存在Try接口的时候+1，但是出现异常，这时候调用Cancel接口库存+1，进行补偿。 优缺点：避免了分布式事务，实现了最终一致性，缺点是需要代码补偿，工作量比较大，幂等需要手动保证。
本地消息表（分布式事务异步通信）
源于ebay，是一种分布式事务异步通信的解决方案。
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
MQ 事务消息
第一阶段Prepared消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
优缺点：实现了最终一致性，不需要依赖本地数据库事务，目前主流MQ中只有RocketMQ支持事务消息。 MQ详解链接
