浅谈分布式事务

背景介绍：

1、锁的本质，资源的操作不是原子 -------- 锁目标，让一系列操作，一次性做完。排队

2、分布式环境下，一切能够发出两个信号量事物都能够做锁 ----- 做锁要求：加锁/解锁两个动作，一定是原子的

3、mysql来做锁 ------- 一条sql的执行，是原子的

4、redis有做锁 -------- setnx操作，是原子的

5、redis要做安全的锁，----- 加锁进程死掉，--------  有效期使用解锁过程复杂化--锁判断----lua脚本来保证原子性

6、锁 ---- 多个线程操作一个资源 ; 事务 ----- 一个线程，操作多个资源问题。

7、事务 ----- ACID ----- 启事务/commit/rollback

8、X/open组织提出分布式事务规范 ---- XA

1、事务执行的中间态说明：

----- sql执行后，尚未提交 ，此时对应的数据状态：

                   -----正本数据（原来的数据）   ----- 锁定状态-------允许其它线程读不允许改（此时易出现幻读）

                   -----副本数据（sql执行结果）  ------ 隔离状态 ------其它线程是无法接触到的-------（可设置事务隔离级别，使其可读）未生效的数据 ---- 脏读

                   ----- commit/rollback时出错     ------- 不能执行机率非常低

 

2、预置一个事务问题场景：去哪网上订购机票

国航：北京 ---- 香港

南航：香港 ----- 泰国

 

只有同时能在国航/南航买到机票，才算有意义，否则做退票处理！

 

一、XA规范下的2pc事务，下面用到的技术是Spring JTA

2pc步骤：

1、引入包

2配置xadatasource --- 2pc方式需要支持XA协议的数据源

3、代码示例 ------- 默认只有runtime（包括其子类）异常回滚 --------普通异常Exception是不回滚的

只要doOrder方法里抛出了RuntimeException，则两个数据库里的sql结果，都会被回滚掉

 

二、 2pc在现实使用中的问题/限制：

1、必须要使用支持XA协议的datasource数据源

2、因为要同时锁定两个数据库的数据，事务锁定时间大大延长 ------ 现实中数据库性能欠佳

 

三、base理论/柔性事务 ----- 为了可用性，牺牲一致性

 

1、base理论的本质，是不再遵守ACID标准，不做强一致性

2、base理论的S，即指事务执行的中间状态（commit之前的状态），可以不隔离锁定，允许对外界表现出不一致

-----------一个事务执行需要时间 ------- a步骤---》b步骤 -------- 20毫秒 ---- 中间状态

3、base理论的E，即指保证最终所有的步骤都得到执行，达到最终数据是一致的

4、整个base理论的过程，如下：

事务开始前 ----- 数据是一致的

事务进行中 ------ 数据是不一致的 ---- 中间态不一致 ---- 放宽标准

事务结束后 ------ 数据又一致

5、对比ACID事务，base事务就是砍掉其中的数据锁定状态

----------------为了可用性 --- 数据锁定的状态--- 不可用状态

6、业界对事务分类标准：

ACID标准，强一致性要求的事务标准 ----- 刚性事务

牺牲一致，放弃ACID里的强一致要求-------柔性事务：

 

四、tcc两阶段、补偿性事务

1、业务接口改造：

一个普通业务接口-----切成三个接口：try--confirm--cancel

try    ------- 原业务接口------- 接口执行完毕，数据库数据就提交 ----如： insert一条数据1

confirm ------ 确认数据 --------- 将try阶段的数据查询出来确认，如： select 1确认数据是否已ok

cancel -------- 抵消数据 --------- 将try阶段的数据做逆向取消，如： delete from删除数据/ insert  -1再加一条数据抵消  ------- 逆向业务方法，又称之谓补偿动作

2、try -confirm-cancel的三个步骤联动过程

如果try不出正常结束，则框架自动去调用confirm方法

如果try出了异常，框架去调用cancel补偿方法

3、tcc方案，对原业务的侵入性太强。为了更好控制，通常做变种使用

try    ------- 将原业务接口，涉及到的资源锁定/或者做预备 ------ 通过一个冻结状态，做排它处理

confirm ------ 正式调用原业务接口方法，如：insert一条数据1 ----- 因try阶段已经为此语句准备好了执行条件，不会再出现业务的冲突情况（业务一定是可行的）

cancel -------- 恢复资源状态，取消资源的冻结状态

4、tcc-transation框架方案实战

（1）、引入pom

（2）、配置tcc数据源

（3）、tcc事务的日志表，TCC_TRANSACTION_ENJOY这张，是由_ENJOY

 

（4）代码逻辑如下：其中confirm指定确认方法，cancelMethod指定补偿方法

（5）tcc框架对业务方法的要求：

try-confirm-cancel三个方法，都必须要满足幂等性/可查询性

（6）tcc事务，与其它事务框架的对比

异步确保型事务

-------- 典型的使用MQ中间件来传递事务调用。

-------- 其重点是确保事务消息一定会传达到目标系统，目标系统只许成功不许失败（不成功我也不管）

-------- 因为是异步的，因此事务发起后，就不再关注了。名曰事务，已不像事务范畴

 

最大努力通知型

-------- 通过多线程异步重试，来传递事务调用

-------- 即通过重试机制，努力将事务调用传递到目标系统，目标系统只许成功不许失败（不成功我也不管）

-------- 因为是异步的，其执行已经脱离事务范畴