背景介绍:
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中间件来传递事务调用。
-------- 其重点是确保事务消息一定会传达到目标系统,目标系统只许成功不许失败(不成功我也不管)
-------- 因为是异步的,因此事务发起后,就不再关注了。名曰事务,已不像事务范畴
最大努力通知型
-------- 通过多线程异步重试,来传递事务调用
-------- 即通过重试机制,努力将事务调用传递到目标系统,目标系统只许成功不许失败(不成功我也不管)
-------- 因为是异步的,其执行已经脱离事务范畴