一次面试后，对于自己对于事务的理解感觉还是太让人失望了，所以专门整理一篇关于事务的内容。

什么是事务？

事务是通过Transaction是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。

基本原则：

ACID：原子性、一致性、隔离性、持久性

为什么引入“事务”这个概念？

** 就像所有的文学，来自与生活，却又高于生活一样。事务的概念同样的来自于生活，引入“事务”肯定是为了解决某种问题，不然，谁愿意干这么无聊的事情呢？**

** 现实里好比银行转账一样，当从一个帐户转出一部分钱之后，就必须在另一个帐户中存入相同数目的钱，若是转出钱之后，事务中止了，没有在另一个帐户中存钱，那么钱就不翼而飞了（事务的原子性），这事肯定是搁在谁身上都是不干的事情。而在软件中由于“事务”与数据库相关，在这个数字化时代，一切即数字，当然包括钱了。这么重要的东西一定得有所保障，既然“事务”能为它提供保障，那么引入它也是理所当然的。**

事务：

CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

• 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
• 可用性(Availability) ： 每个操作都必须以可预期的响应结束
• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成

XA 是一个两阶段提交协议，该协议分为以下两个阶段：

• 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
• 第二阶段：事务协调器要求每个数据库提交数据。

BASE理论

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

二、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

• Try 阶段主要是对业务系统做检测及资源预留
• Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

三、本地消息表

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

四、MQ 事务消息

第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务，
第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

五、Sagas 事务模型

Saga事务模型又叫做长时间运行的事务（Long-running-transaction）
工作流事务模型控制
分布式事务解决方案：CAP