参考连接分布式事务有这一篇就够了！ - 知乎 (zhihu.com)

本地事务

使用服务自己的数据库来控制事务，我们常使用的transaction注解。transaction注解是基于spring基于aop思想利用数据库的事务来进行事务控制。

begin transaction；
    //1.本地数据库操作：张三减少金额
    //2.本地数据库操作：李四增加金额
commit transation;

分布式事务

begin transaction；
    //1.本地数据库操作：张三减少金额
    //2.远程调用：让李四增加金额
commit transation;

 也就是说远程调用的事务操作成功，已经提交了但是我们由于其他原因网络等，到时长时间没有返回，那么本地事务就会回滚，这样我们的张三的金额恢复之前的状态，但是我们的远程调用的事务并没有恢复之前的状态，这时候我们就要进行分布式事务控制。

产生分布式事务的其他情况，注意不一定都是操作数据库，也可是我们上面的操作redis和操作minio等

1. 跨JVM进程产生分布式事务
   典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。

1. 跨数据库实例产生分布式事务
   单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。

1. 多服务访问同一个数据库实例
   订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

也就是说我们之前的在一个微服务中操作一个数据库的多张表不是分布式事务，这是一个本地事务，因此我们可以使用transaction注解进行解决。但是如果产生了多个连接，那么就是分布式事务。

2. 分布式事务基础理论和技术方案

4.2.2 什么是CAP理论

控制分布式事务首先需要理解CAP理论，什么是CAP理论？

CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。

使用下边的分布式系统结构 进行说明：

客户端经过网关访问用户服务的两个结点，一致性是指用户不管访问哪一个结点拿到的数据都是最新的，比如查询小明的信息，不能出现在数据没有改变的情况下两次查询结果不一样。

可用性是指任何时候查询用户信息都可以查询到结果，但不保证查询到最新的数据。

分区容忍性也叫分区容错性，当系统采用分布式架构时由于网络通信异常导致请求中断、消息丢失，但系统依然对外提供服务。

CAP理论要强调的是在分布式系统中这三点不可能全部满足，由于是分布式系统就要满足分区容忍性，因为服务之间难免出现网络异常，不能因为局部网络异常导致整个系统不可用。

满足P那么C和A不能同时满足：

比如我们添加一个用户小明的信息，该信息先添加到结点1中，再同步到结点2中，如下图：

如果要满足C一致性，必须等待小明的信息同步完成系统才可用（否则会出现请求到结点2时查询不到数据，违反了一致性），在信息同步过程中系统是不可用的，所以满足C的同时无法满足A。

如果要满足A可用性，要时刻保证系统可用就不用等待信息同步完成，此时系统的一致性无法满足。

所以在分布式系统中进行分布式事务控制，要么保证CP、要么保证AP。

4.2.3 分布式事务控制方案

学习了CAP理论该如何控制分布式事务呢？

学习了CAP理论我们知道进行分布式事务控制要在C和A中作出取舍，保证一致性就不要保证可用性，保证可用性就不要保证一致，首先你确认是要CP还是AP，具体要根据应用场景进行判断。

CP的场景：满足C舍弃A，强调一致性。

跨行转账：一次转账请求要等待双方银行系统都完成整个事务才算完成，只要其中一个失败另一方执行回滚操作。

开户操作：在业务系统开户同时要在运营商开户，任何一方开户失败该用户都不可使用，所以要满足CP。

AP的场景：满足A舍弃C，强调可用性。

订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。

注册送积分，注册成功积分在24分到账。

支付短信通信，支付成功发短信，短信发送可以有延迟，甚至没有发送成功。

在实际应用中符合AP的场景较多，其实虽然AP舍弃C一致性，实际上最终数据还是达到了一致，也就满足了最终一致性，所以业界定义了BASE理论。

什么是BASE理论？

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。

基本可用：当系统无法满足全部可用时保证核心服务可用即可，比如一个外卖系统，每到中午12点左右系统并发量很高，此时要保证下单流程涉及的服务可用，其它服务暂时不可用。

软状态：是指可以存在中间状态，比如：打印自己的社保统计情况，该操作不会立即出现结果，而是提示你打印中，请在XXX时间后查收。虽然出现了中间状态，但最终状态是正确的。

最终一致性：退款操作后没有及时到账，经过一定的时间后账户到账，舍弃强一致性，满足最终一致性。

分布式事务控制有哪些常用的技术方案？

实现CP就是要实现强一致性:

使用Seata框架基于XA模式实现 

实现AP则要保证最终数据一致性:

使用Seata框架基于TCC模式实现

使用Seata框架基于AT模式实现

使用消息队列通知的方式去实现，通知失败自动重试，达到最大失败次数需要人工处理；

使用任务调度的方案，启动任务调度将课程信息由数据库同步到elasticsearch、MinIO、redis中。

项目技术选型

我们的项目是基于AP方式并且保证数据最终一致性。 我们项目没有使用rabbitmq技术进行实现，我们使用了任务调度的方式来实现，简要流程就是每次发布课程都要将课程写在消息表，然后任务方法读取消息表然后从数据库中查询数据，完成其他任务。

目前我们已经有了任务调度的技术积累，这里选用任务调度的方案去实现分布式事务控制，课程发布满足AP即可。

下图是具体的技术方案：

1、在内容管理服务的数据库中添加一个消息表，消息表和课程发布表在同一个数据库。

2、点击课程发布通过本地事务向课程发布表写入课程发布信息，同时向消息表写课程发布的消息。通过数据库进行控制，只要课程发布表插入成功消息表也插入成功，消息表的数据就记录了某门课程发布的任务。

3、启动任务调度系统定时调度内容管理服务去定时扫描消息表的记录。

4、当扫描到课程发布的消息时即开始完成向redis、elasticsearch、MinIO同步数据的操作。

5、同步数据的任务完成后删除消息表记录。