什么是分布式事务？

首先理解什么是本地事务

平时我们在程序中通过Spring去控制事务是利用数据库本身的事务特性来实现的，因此叫数据库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务
本地事务具有ACID四大特性

  • 原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的操作要么全部成功，要么全部失败。
  • 一致性（Consistency）：事务在执行前后必须保持数据的一致性，即满足业务逻辑和约束条件。
  • 隔离性（Isolation）：事务之间不应相互干扰，每个事务都应该在独立的环境中执行，不受其他事务的影响。
  • 持久性（Durability）：事务一旦提交，其对数据的修改就应该永久保存在数据库中，即使发生系统故障或崩溃也不会丢失。
    数据库事务在实现时会将一次事务涉及到的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚
理解了本地事务，那么什么是分布式事务？

现在的需求是：课程发布操作后，将数据写入数据库、Redis、ElasticSearch、MinIO四个地方，这四个地方已经不限制在一个数据库内，而是由四个分散的服务去提供，与这四个服务去通信需要网络通信，而网络存在不可到达性（例如突然断网），在这种分布式系统环境下，通过与不同的服务进行网络通信去完成事务，称之为分布式事务
在分布式系统中分布式事务的场景有很多，例如用户注册送积分、银行转账、创建订单减库存，这些都是分布式事务
拿转账举例，我们知道本地事务依赖数据库本身提供的事务特性来实现，因此以下逻辑可以控制本地事务

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

但是在分布式环境下，会变成这样

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

可以设想，当远程调用让李四增加金额成功了，由于网络原因导致远程调用的结果没有返回，此时本地事务提交失败就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了
因此在分布式框架的基础上，传统数据库事务就无法使用了，张三和李四的账户不在同一个数据库甚至不在同一个应用系统里，实现转账事务需要远程调用，由于网络问题就会导致分布式事务问题

什么是CAP理论

控制分布式事务首先需要理解CAP理论，什么是CAP理论？
CAP理论是一个分布式系统设计的重要理论，它指出一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。

  • 一致性是指所有节点访问同一份最新的数据副本
  • 可用性是指每个请求都能得到响应
  • 分区容忍性是指系统能够在网络分区的情况下继续运行。

举例：一个网关两个节点
客户端经过网关访问用户服务的两个节点
一致性是指用户不管访问哪一个节点，拿到的数据都是最新的相同的，例如查询小明的信息，不能出现在数据没有改变的情况下，两次查询结果不一样
可用性是指任何时候查询用户信息都可以查询到结果，但是不保证查询到的是最新的数据
分区容忍性也叫分区容错性，由于网络通信异常，导致请求终端、消息丢失，单服务依然对外提供服务

CAP理论要强调的是在分布式系统中，这三点不可能全部满足，因为只要是分布式系统就要满足分区容忍性，因为服务间难免会出现网络异常，不能因为局部网络异常就导致整个系统不可用
满足分区容忍性的条件下，一致性和可用性不能同时满足
例如我们添加一个用户小明的信息，该信息先添加到结点1中，再同步到结点2中
如果满足C一致性，必须等待小明的信息同步完成后，系统才可用（否则当你查询结点2的时候，会查不到数据，违背了一致性）
如果满足A可用性，要时刻保证系统可用，就不用等待信息同步完成，此时系统的一致性就无法满足
所以C和A不能同时满足，在分布式系统中进行分布式事务控制，要么保证CP、要么保证AP

分布式事务控制方案

学习CAP理论，我们知道进行分布式事务控制要在C一致性和A可用性中做出取舍，保证一致性就不要保证可用性，保证可用性就不要保证一致性。
首先要确认我们的需求是要CP还是AP，具体要根据应用场景进行判断
CP的场景：满足C舍弃A，强调一致性
跨行转账：一次转账请求要等待双方银行系统都完成整个事务才算完成，只要其中一个失败，另一方执行回滚操作
开户操作：在业务系统开户同时要在运营商开户，任何一方开户失败，该用户都不可使用新开账户，要满足一致性
AP的场景：满足A舍弃C，强调可用性
订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可
注册送积分，注册成功，积分在24小时内到账
支付短信通信，支付成功发短信，短信发送可以有延迟
在实际应用中符合AP的场景比较多，虽然AP舍弃C的一致性，但实际最终数据还是保持了一致，所以业界定义了BASE理论

BASE 理论

BASE是Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。
基本可用：当系统无法满足全部可用时，保证核心业务可用即可，比如一个外卖系统，到了饭点的时候系统并发量很高，此时要保证下单流程涉及的服务可用，其他服务暂不可用
软状态：可以存在中间状态，例如：微博的评论功能。当用户发表一条评论时，这条评论并不会立即同步到所有关注者的页面上，而是会先存储在缓存中，并逐渐传播到其他节点。这样就存在了一个中间状态，即某些用户可以看到这条评论，而某些用户还不能看到。
最终一致性：前面的软状态并不影响微博的整体可用性，用户仍然可以正常浏览和发表微博。最终，在一定时间内，所有关注者都能看到这条评论，达到了最终一致性。

分布式事务常见的技术方案

实现CP就需要强一致性：
例如Seata AT模式、TCC模式
实现AP保证最终一致性：
消息队列，通知失败自动重试，超过最大次数手动处理、任务调度

在我们的系统中，课程发布操作后，将数据写入数据库、Redis、ElasticSearch、MinIO，采用定时任务，利用将发布课程消息表来记录任务，任务完成删除消息表记录，任务没完成则下一轮定时任务会重新执行。