【愚公系列】2023年11月 Java教学课程 215-分布式事务（理论基础）

🚀前言

事务是指一组操作序列，在这个序列中，要么所有操作都成功完成并且对数据进行了正确的更新，否则所有操作都应该无效，以保持数据的一致性。

常用的事务类型：

不同的技术或系统中支持的事务类型和实现细节可能会有所不同，以上只是一些常见的事务类型。同时，在微服务架构中，可能会使用以事件为驱动的分布式事务或者最终一致性等方式来处理事务。

🚀一、分布式事务问题

🔎1.本地事务

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：

🔎2.分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

• 跨数据源的分布式事务
• 跨服务的分布式事务
• 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单
• 扣减商品库存
• 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

🔎3.演示分布式事务问题

1、创建数据库，名为seata_demo，然后执行下面sql语句：

/*
 Navicat Premium Data Transfer

 Source Server         : local
 Source Server Type    : MySQL
 Source Server Version : 50622
 Source Host           : localhost:3306
 Source Schema         : seata_demo

 Target Server Type    : MySQL
 Target Server Version : 50622
 File Encoding         : 65001

 Date: 24/06/2021 19:55:35
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for account_tbl
-- ----------------------------
DROP TABLE IF EXISTS `account_tbl`;
CREATE TABLE `account_tbl`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `money` int(11) UNSIGNED NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of account_tbl
-- ----------------------------
INSERT INTO `account_tbl` VALUES (1, 'user202103032042012', 1000);

-- ----------------------------
-- Table structure for order_tbl
-- ----------------------------
DROP TABLE IF EXISTS `order_tbl`;
CREATE TABLE `order_tbl`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `commodity_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `count` int(11) NULL DEFAULT 0,
  `money` int(11) NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of order_tbl
-- ----------------------------

-- ----------------------------
-- Table structure for storage_tbl
-- ----------------------------
DROP TABLE IF EXISTS `storage_tbl`;
CREATE TABLE `storage_tbl`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `commodity_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `count` int(11) UNSIGNED NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `commodity_code`(`commodity_code`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

-- ----------------------------
-- Records of storage_tbl
-- ----------------------------
INSERT INTO `storage_tbl` VALUES (1, '100202003032041', 10);

SET FOREIGN_KEY_CHECKS = 1;

2、创建工程，名为seata_demo：

其中：

seata-demo：父工程，负责管理项目依赖

• account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口
• storage-service：库存服务，负责管理商品库存。提供扣减库存的接口
• order-service：订单服务，负责管理订单。创建订单时，需要调用account-service和storage-service

3）启动nacos、所有微服务

4）测试下单功能，发出Post请求：

请求如下：

curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'

如图：

测试发现，当库存不足时，如果余额已经扣减，并不会回滚，出现了分布式事务问题。

🚀二、理论基础

🔎1.CAP定理

CAP定理是指在数据存储系统中，一致性、可用性和分区容忍度三个方面不可能同时满足。其中：

• 一致性（Consistency）指的是数据在多个节点之间的同步更新。如果一个操作成功更新了某个节点上的数据，那么在其他节点上也必须立即更新该数据，即保证数据一致性。但是，一致性要求所有节点都必须参与更新，因此更新速度会受到影响。
• 可用性（Availability）指的是系统必须随时对外提供服务，不论系统内部任何节点是否故障，用户都能够得到相应的响应。但是，为了提高可用性，有些节点可能会被设计成“从节点”，这些节点无法直接参与数据的更新，因此会牺牲一致性。
• 分区容忍度（Partition Tolerance）指的是数据存储系统在遇到网络分区（节点之间无法通信）的情况下，仍然能够正常工作。为了保证分区容忍度，系统需要将数据分布到不同节点上，但是节点之间无法即时同步更新数据，因此会影响一致性。

CAP定理指出，数据存储系统不可能同时满足这三个方面。在分布式系统中，需要根据业务需求，权衡这三个方面的要求，找到最优的解决方案。

🦋2.1 一致性

CAP 定理中的一致性（Consistency）指的是，在分布式系统中的所有节点都进行了某个操作之后，系统必须保证每个节点看到的数据都是一致的。换句话说，任何时候，任何节点在查询数据时都应该能够获得最新的、正确的数据。

为了实现一致性，分布式系统通常会采用复制机制，即将数据复制到多个节点上，以确保数据的一致性。一般来说，在一个节点上对数据进行的任何修改都应该同步到其他节点上。这就需要使用一些分布式一致性协议来确保节点之间的数据同步。

但是，实现一致性往往需要付出较高的代价，比如延迟和系统复杂度的增加。因此，在 CAP 定理中，一致性和可用性之间存在着一种权衡关系，系统设计者需要根据具体的业务需求和性能要求来做出取舍。

比如现在包含两个节点，其中的初始数据是一致的：

当我们修改其中一个节点的数据时，两者的数据产生了差异：

要想保住一致性，就必须实现node01 到 node02的数据 同步：

🦋2.2 可用性

CAP定理中的Availability（可用性）指的是系统能够在任何时候响应客户端请求，即使在发生网络分区时仍能保持运行和响应。但这也意味着系统可能需要牺牲一致性。在发生网络分区时，即使不同节点之间数据不一致，也要保证客户端可以得到响应。

如图，有三个节点的集群，访问任何一个都可以及时得到响应：

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：

🦋2.3 分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

例如，对于一个在线商城系统，可用性和分区容忍性都是非常重要的，因为用户需要实时访问和操作系统，并且该系统可能会面临网络分区或者服务器宕机等情况。而一致性则可以在系统设计时进行一定程度的折衷，比如采用最终一致性的方案来保证数据的最终一致性。

🦋2.4 矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务又必须对外保证服务。因此Partition Tolerance不可避免。

当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

🔎2.BASE理论

BASE理论是一个用于描述分布式系统的一组属性，它包含以下四个单词的首字母缩写：

• B：基本可用，即系统保证在出现故障时的可用性和可靠性，而不是100%的可用性。
• A：软状态，即系统有可能在短时间内存在不一致的状态，但最终会达到一致状态。
• S：最终一致性，即系统保证数据在一定时间内达到一致状态，但可能会存在一段时间内的数据不一致。
• E：分区容错性，即系统在分区出现故障时，仍然能够保证数据的可用性和一致性。

BASE理论是对传统ACID事务模型的一种补充，它在妥协一致性的前提下，保证系统的可用性和性能。BASE理论的核心思想是通过松散的一致性要求，以换取更高的可用性和性能。

🔎3.解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

🚀感谢：给读者的一封信

亲爱的读者，

我在这篇文章中投入了大量的心血和时间，希望为您提供有价值的内容。这篇文章包含了深入的研究和个人经验，我相信这些信息对您非常有帮助。

如果您觉得这篇文章对您有所帮助，我诚恳地请求您考虑赞赏1元钱的支持。这个金额不会对您的财务状况造成负担，但它会对我继续创作高质量的内容产生积极的影响。

我之所以写这篇文章，是因为我热爱分享有用的知识和见解。您的支持将帮助我继续这个使命，也鼓励我花更多的时间和精力创作更多有价值的内容。