关于分布式事务管理整理归纳

事务：首先事务是什么？

事务就是当我们在发送一个请求的时候，通常会调用很多方法，我们把与这个请求相关的方法全部看成一个整体也就是一个事务，那么我们在执行该请求的时候如果中途出现异常那么我们之前的操作的数据都应该回到我们请求前的状态；这样才不会导致数据出现不一致的情况；

事务就有以下四种特性：

• 原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
• 一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。
• 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
• 持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。

那么我们在什么地方需要使用到事务？

事务几乎贯穿我们代码执行的各个角落，它是一种理念，类似于我们java中的对象的思想，我们可以将一个请求中所有要执行的方法称之为一个请求，同样我们也可以将该请求堪称时一个事务，所以事务尤其是我们在操作数据库数据的时候，一定要用到事务，那通常我们可以使用@Transactional来保证本地该类中的方法是支持事务的；但是当我们在分布式的环境中我们需要调用其他服务的方法的时候使用@Transactional只能保证当前服务的方法是支持事物的，却不能保证其他服务的方法支持该事务，这时候我们就需要只用到微服务中的分布式事务来解决该问题了；

二、分布式事务理论

cap理论：

C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。

A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。

P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

对于分布式，P是必须的，CA选其一达成CP(牺牲一点可用达成强一致)、AP(牺牲一点一致性达成高可用)。同时对于被牺牲的那个特性，也要尽可能保证。

比如你选择了CP，并不是叫你放弃A。因为P出现的概率实在是太小了，大部分的时间你仍然需要保证CA。就算分区出现了你也要为后来的A做准备，比如通过一些日志的手段，使其他机器恢复至可用

 

三、分布式事务常见解决方案以及区别：

目前业界提供的解决方案

业界目前主流的分布式事务解决方案主要有：多阶段提交方案（2PC、3PC）、补偿事务（TCC）和消息事务（主要是RocketMQ，基本思想也是多阶段提交方案，其他消息队列中间件并没有实现分布式事务）。这些方案的原理在此处不展开，目前网络中相应资料比较多，小结一下它们的特点：

• 多阶段提交方案：常见的有二阶段和三阶段提交事务，需要额外的资源管理器来协调事务，数据一致性强，但是实现方案比较复杂，对性能的牺牲比较大（主要是需要对资源锁定，等待所有事务提交才能解锁），不适用于高并发的场景，目前比较知名的有阿里开源的fescar。
• 补偿事务：一般也叫TCC，因为每个事务操作都需要提供三个操作尝试（Try）、确认（Confirm）和补偿/撤销（Cancel），数据一致性的强度比多阶段提交方案低，但是实现的复杂度会有所降低，比较明显的缺陷是每个业务事务需要实现三组操作，有可能出现过多的补偿方案的代码；另外有很多场景TCC是不合适的。
• 消息事务：这里只谈RocketMQ的实现，一个事务的执行流程包括：发送预消息、执行本地事务、确认消息发送成功。它的消息中间件存储了下游无法消费成功的消息，并且不断重试推送下游消费消息，而生产者（上游）需要提供一个check接口，用于检查成功发送预消息但是未确认最终消息发送状态的事务的状态。