From ee938ffa19faa1d0c6cd68f6fcc06aeaf85d91fa Mon Sep 17 00:00:00 2001 From: "jimin.jm" Date: Tue, 12 Feb 2019 10:35:47 +0800 Subject: [PATCH] doc init --- .gitignore | 3 + README.md | 13 ++- wiki/zh-cn/Fescar-AT.md | 204 ++++++++++++++++++++++++++++++++++++++++ wiki/zh-cn/Fescar-MT.md | 26 +++++ 4 files changed, 245 insertions(+), 1 deletion(-) create mode 100644 .gitignore create mode 100644 wiki/zh-cn/Fescar-AT.md create mode 100644 wiki/zh-cn/Fescar-MT.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..85a192e --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +# Created by .ignore support plugin (hsz.mobi) +fescar-awesome.iml +.idea \ No newline at end of file diff --git a/README.md b/README.md index dd35aa0..2555880 100644 --- a/README.md +++ b/README.md @@ -1 +1,12 @@ -# fescar-awesome \ No newline at end of file +# fescar-awesome + + +提交文章时请在文章开头以注释的形式标名文章标题，文章作者，文章关键词，文章日期 + + +--- +title: +author: +keywords: +date: +--- \ No newline at end of file diff --git a/wiki/zh-cn/Fescar-AT.md b/wiki/zh-cn/Fescar-AT.md new file mode 100644 index 0000000..3fac2bb --- /dev/null +++ b/wiki/zh-cn/Fescar-AT.md @@ -0,0 +1,204 @@ +# 基本思路 + +## 前提 + +- 基于支持本地 ACID 事务的关系型数据库。 +- Java 应用，通过 JDBC 访问数据库。 + +## 整体机制 + +两阶段提交协议的演变： + +- 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。 +- 二阶段： + + - 提交异步化，非常快速地完成。 + - 回滚通过一阶段的回滚日志进行反向补偿。 + + +# 写隔离 + +- 一阶段本地事务提交前，需要确保先拿到 **全局锁** 。 +- 拿不到 **全局锁** ，不能提交本地事务。 +- 拿 **全局锁** 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。 + +以一个示例来说明： + +两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。 + +tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 **全局锁** ，本地提交释放本地锁。 +tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 **全局锁** ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 **全局锁** 。 + +![Write-Isolation: Commit](https://upload-images.jianshu.io/upload_images/4420767-90b8bf0388953ee8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + +tx1 二阶段全局提交，释放 **全局锁** 。tx2 拿到 **全局锁** 提交本地事务。 + +![Write-Isolation: Rollback](https://upload-images.jianshu.io/upload_images/4420767-434090412a6a07b8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + +如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。 + +此时，如果 tx2 仍在等待该数据的 **全局锁**，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 **全局锁** 等锁超时，放弃 **全局锁** 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。 + +因为整个过程 **全局锁** 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 **脏写** 的问题。 + +# 读隔离 + +在数据库本地事务隔离级别 **读已提交（Read Committed）** 或以上的基础上，Fescar（AT 模式）的默认全局隔离级别是 **读未提交（Read Uncommitted）** 。 + +如果应用在特定场景下，必需要求全局的 **读已提交** ，目前 Fescar 的方式是通过 SELECT FOR UPDATE 语句的代理。 + +![Read Isolation: SELECT FOR UPDATE](https://upload-images.jianshu.io/upload_images/4420767-6236f075d02c5e34.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + +SELECT FOR UPDATE 语句的执行会申请 **全局锁** ，如果 **全局锁** 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 **全局锁** 拿到，即读取的相关数据是 **已提交** 的，才返回。 + +出于总体性能上的考虑，Fescar 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。 + +# 工作机制 + +以一个示例来说明整个 AT 分支的工作过程。 + +业务表：`product` + +| Field | Type | Key| +|---------------|--------------|----| +| id | bigint(20) |PRI | +| name | varchar(100) | | +| since | varchar(100) | | + +AT 分支事务的业务逻辑： + +```sql +update product set name = 'GTS' where name = 'TXC'; +``` +## 一阶段 + +过程： + +1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息。 +2. 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。 + +```sql +select id, name, since from product where name = 'TXC'; +``` +得到前镜像： + +|id|name|since| +|---|---|---| +|1|TXC|2014| + + +3. 执行业务 SQL：更新这条记录的 name 为 'GTS'。 +4. 查询后镜像：根据前镜像的结果，通过 **主键** 定位数据。 + +```sql +select id, name, since from product where id = 1`; +``` +得到后镜像： + +|id|name|since| +|---|---|---| +|1|GTS|2014| + +5. 插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 `UNDO_LOG` 表中。 + +```json +{ + "branchId": 641789253, + "undoItems": [{ + "afterImage": { + "rows": [{ + "fields": [{ + "name": "id", + "type": 4, + "value": 1 + }, { + "name": "name", + "type": 12, + "value": "GTS" + }, { + "name": "since", + "type": 12, + "value": "2014" + }] + }], + "tableName": "product" + }, + "beforeImage": { + "rows": [{ + "fields": [{ + "name": "id", + "type": 4, + "value": 1 + }, { + "name": "name", + "type": 12, + "value": "TXC" + }, { + "name": "since", + "type": 12, + "value": "2014" + }] + }], + "tableName": "product" + }, + "sqlType": "UPDATE" + }], + "xid": "xid:xxx" +} +``` + +6. 提交前，向 TC 注册分支：申请 `product` 表中，主键值等于 1 的记录的 **全局锁** 。 +7. 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。 +8. 将本地事务提交的结果上报给 TC。 + +## 二阶段-回滚 + +1. 收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。 +2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。 +3. 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。 +4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句： + +```sql +update product set name = 'TXC' where id = 1; +``` + +5. 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。 + +## 二阶段-提交 + +1. 收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。 +2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。 + + +# 附录 + +## 回滚日志表 + +UNDO_LOG Table：不同数据库在类型上会略有差别。 + +以 MySQL 为例： + +| Field | Type | +|---------------|--------------| +| branch_id | bigint PK| +| xid | varchar(100) | +| rollback_info | longblob | +| log_status | tinyint | +| log_created | datetime | +| log_modified | datetime | +| ext | varchar(100) | + +```sql +CREATE TABLE `undo_log` ( + `id` bigint(20) NOT NULL AUTO_INCREMENT, + `branch_id` bigint(20) NOT NULL, + `xid` varchar(100) NOT NULL, + `rollback_info` longblob NOT NULL, + `log_status` int(11) NOT NULL, + `log_created` datetime NOT NULL, + `log_modified` datetime NOT NULL, + `ext` varchar(100), + PRIMARY KEY (`id`), + KEY `idx_unionkey` (`xid`,`branch_id`) +) ENGINE=InnoDB DEFAULT CHARSET=utf8; +``` \ No newline at end of file diff --git a/wiki/zh-cn/Fescar-MT.md b/wiki/zh-cn/Fescar-MT.md new file mode 100644 index 0000000..1e240e3 --- /dev/null +++ b/wiki/zh-cn/Fescar-MT.md @@ -0,0 +1,26 @@ +# Manual Transaction 模式 + +回顾总览中的描述：一个分布式的全局事务，整体是 **两阶段提交** 的模型。全局事务是由若干分支事务组成的，分支事务要满足 **两阶段提交** 的模型要求，即需要每个分支事务都具备自己的： + +- 一阶段 prepare 行为 +- 二阶段 commit 或 rollback 行为 + +![Overview of a global transaction](https://upload-images.jianshu.io/upload_images/4420767-e48f0284a037d1df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) + +根据两阶段行为模式的不同，我们将分支事务划分为 **Automatic (Branch) Transaction Mode** 和 **Manual (Branch) Transaction Mode**. + +AT 模式（[参考链接 TBD]()）基于 **支持本地 ACID 事务** 的 **关系型数据库**： + +- 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。 +- 二阶段 commit 行为：马上成功结束，**自动** 异步批量清理回滚日志。 +- 二阶段 rollback 行为：通过回滚日志，**自动** 生成补偿操作，完成数据回滚。 + +相应的，MT 模式，不依赖于底层数据资源的事务支持： + +- 一阶段 prepare 行为：调用 **自定义** 的 prepare 逻辑。 +- 二阶段 commit 行为：调用 **自定义** 的 commit 逻辑。 +- 二阶段 rollback 行为：调用 **自定义** 的 rollback 逻辑。 + +所谓 MT 模式，是指支持把 **自定义** 的分支事务纳入到全局事务的管理中。 + +