Fescar全局锁的理解
前几天夜里,我老大发我一篇文章说阿里的GTS开源了。 因为一直对分布式事务比较感兴趣,立马pull了代码,进行阅读。基本的原理,实现方案我就不一一细化了,详细见官方文档(写的很棒,点赞)。
在fescar的社区,大家比较关注的是通过fescar回滚到before快照前,别的线程假如更新了数据,且业务走完了,那么恢复的这个快照不就是脏数据了么。 很显然,这种情况在fescar中是不被允许的。
那么fescar是如何做的呢?
我们先简单了解一下fescar的设计原理
那些一上来就喜欢看源码的同学,一定不要错过这么官方的图文介绍,看完再读源码事半功倍。
Fescar官方介绍(https://github.com/alibaba/fescar/wiki)
了解完Fescar的基本原理,我们重点关注下Fescar的全局排他锁
Fescar设计了一个全局的排他锁,来保证事务间的 写隔离。
关于隔离性:(这是Fescar官方给的一段话)
全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。
在数据库本地隔离级别 读已提交或以上 的前提下,Fescar 设计了由事务协调器维护的 全局写排他锁,来保证事务间的 写隔离,将 全局事务默认定义在 读未提交 的隔离级别上。
我们对隔离级别的共识是:绝大部分应用在读已提交的隔离级别下工作是没有问题的。而实际上,这当中又有绝大多数的应用场景,实际上工作在读未提交的隔离级别下同样没有问题。
在极端场景下,应用如果需要达到全局的读已提交,Fescar也提供了相应的机制来达到目的。 默认,Fescar 是工作在 读无提交 的隔离级别下,保证绝大多数场景的高效性。
我的解读
本地事务【读已提交】,fescar全局事务【读未提交】。这是这段话的核心。 我理解的这段话中fescar全局事务读未提交,并不是说本地事务的db数据没有正常提交,而是指全局事务二阶段commit|rollback未真正处理完(即未释放全局锁)。
总结来说:全局未提交但是本地已提交的数据,对其他全局事务是可见的【当然在本地事务提交后,本地事务提交前,隔离级别是本地事务的管辖范围】
for example 产品份额有5W,A用户购买了2万,份额branch一阶段完毕(本地事务份额已经扣除commit),但是在下单的时候异常了。 因为本地事务读已提交,这时候fescar允许业务访问该条数据,3W,在A用户的份额branch未回滚成功前,对其他用户可见。 但是其他用户并不能买该产品,必须等到产品份额回滚到5万,其他用户才可以操作产品数据。
所以看了这个例子 真的有必要做到全局事务读已提交么?
我们先来看一下Fescar的全局锁的做法
Fescar一阶段
1. 本地(Branch)在向TC注册的时候,把本地事务需要修改的数据table+pks提交到server端申请锁,拿到全局锁后,才能提交本地事务
2. 全局锁的结构:resourceId + table + pks
3. 锁是存在server端 branchSession中
Fescar二阶段
一阶段本地事务提交,db的锁释放了(for update锁),但是全局锁继续保持, 直到二阶段决议(注意释放锁的顺序):
1. 提交:TC 释放锁,通知branch提交后 (rm端异步处理)
2. 回滚:TC 通知branch回滚后,释放锁(rm端同步处理 执行undo_log)
Fescar如何保障锁的高效?
大家自己先思考下,最后给大家仔细解读官方的demo,并分析fescar的性能问题。
Fescar目前开源版本全局锁的实现
大家有兴趣自己阅读:com.alibaba.fescar.server.lock.DefaultLockManagerImpl
官方的图实在是做的太漂亮了,clone一份解读 TC TM RM 以及全局锁的获取和释放动作发生点
分支事务如何工作?关注全局锁的获取和释放 特别是二阶段commit和rollback全局锁释放的顺序
Fescar中 RM TM TC如何工作的?
看了这两张图,大家应该对fescar是如何工作的应该有一个大致的了解了。☺
1. 全局锁的获取
2. tm tc rm之间如何通信工作
3. 隔离级别问题的思考
最后我们来解读一遍官方的demo
branch1:update storage
tbl set count = count - ? where commoditycode = ?branch2:update account
tbl set money = money - ? where userid = ?branch3:insert into order
tbl (userid, commodity_code, count, money) values (?, ?, ?, ?)
1. 线程A:执行branch1(pk:55),执行branch2的时候发现没钱了,扔了一个异常,那么势必需要回滚branch1的份额。
TM通知TC开始回滚branch1份额中
2. 线程B:执行branch1(pk:55)
如果线程A中branch1(pk:55)已经回滚成功了,那么B线程可以正常拿到锁走下去
如果线程A中branch1还未回滚(resourceId+table+pk锁未释放)。当线程B发起branch1向server发起申请锁,会直接失败。
Fescar全局锁简单总结:操作一条记录的分支事务,必须等待这条记录的前一个分支事务执行结束(具体commit rollback情况分析如下),才能持有锁。
其实相比XA的锁,fescar在每个分支事务的一阶段结束后都释放了db的锁,所以fescar的性能瓶颈应该在于二阶段的执行速度(释放锁的快慢)
因为分布式事务在执行事务编排前,一般会校验业务的正确性,所以发生回滚的概率相对较低,所以先考虑二阶段commit操作。
1. Commit场景分析:
TM通知server进行commit,server立马释 branch的锁,然后再逐个通知RM提交 消耗:1 rpc操作,(branch删除undo_log放在异步队列里面做)
2. Rollback场景分析:
TM通知server进行rollback,server通知RM回滚后立马释放 branch的锁。 消耗:1 + N的rpc操作 + N的回滚sql操作
所以总的来看fescar在commit的释放全局锁还是非常高效的。
思考
1. server支持多台机器部署,应该如何改造?
全局锁的问题,锁改造; 全局事务向server0申请的,Branch1发到server1,branch2发到server2的问题,多机器恢复的情况,TC的改造
2. 全局锁在Fescar中更新确实是没有问题的,但是如果就是业务方需要手动调整DB数据呢 ?
大胆猜测,依赖Fescar写了一个管理平台 用来执行sql的。哈哈
3. 隔离级别的思考
Fescar默认工作在,本地事务读已提交,全局事务读未提交。 是否存在全局事务必须工作在【读已提交】级别而不能工作在【读未提交】的业务场景呢? 大家大胆脑洞 这个问题值得探讨。
4. Fescar的文档中说,是支持全局事务读已提交的,那么fescar是如何实现的呢?
感兴趣的同学可以试着读一下
com.alibaba.fescar.rm.datasource.exec.SelectForUpdateExecutor复制代码
源码核心类
大家想读源码的话,可以重点关注一下几个类。有问题一起探讨。
TM相关
com.alibaba.fescar.tm.api.TransactionalTemplate
复制代码
RM相关
com.alibaba.fescar.rm.datasource.exec.SelectForUpdateExecutor
com.alibaba.fescar.rm.datasource.ConnectionProxy
com.alibaba.fescar.rm.datasource.exec.AbstractDMLBaseExecutor
com.alibaba.fescar.rm.RMHandlerAT
复制代码
TC相关
com.alibaba.fescar.server.coordinator.DefaultCoordinator
com.alibaba.fescar.server.coordinator.DefaultCore
com.alibaba.fescar.server.lock.DefaultLockManagerImpl
复制代码
- Github:https://github.com/alibaba/fescar
- 官方中文介绍:https://github.com/alibaba/fescar/wiki
作者简介
雨人,铜板街交易团队研发工程师,2016年5月加入铜板街,目前主要负责资金端项目的开发。
更多精彩内容,请扫码关注 “铜板街技术” 微信公众号。