网站改版要重新备案吗,网站不备案有什么后果,做婚纱网站是怎么确认主题,简单的app开发制作前言
一般#xff0c;数据库事务的隔离级别会被设置成 读已提交#xff0c;已满足业务需求#xff0c;这样对应在Fescar中的分支#xff08;本地#xff09;事务的隔离级别就是 读已提交#xff0c;那么Fescar中对于全局事务的隔离级别又是什么呢#xff1f;如果认真阅…前言
一般数据库事务的隔离级别会被设置成 读已提交已满足业务需求这样对应在Fescar中的分支本地事务的隔离级别就是 读已提交那么Fescar中对于全局事务的隔离级别又是什么呢如果认真阅读了 分布式事务中间件Txc/Fescar-RM模块源码解读 的同学应该能推断出来Fescar将全局事务的默认隔离定义成读未提交。对于读未提交隔离级别对业务的影响想必大家都比较清楚会读到脏数据经典的就是银行转账例子出现数据不一致的问题。而对于Fescar如果没有采取任何其它技术手段那会出现很严重的问题比如 如上图所示问最终全局事务A对资源R1应该回滚到哪种状态很明显如果再根据UndoLog去做回滚就会发生严重问题覆盖了全局事务B对资源R1的变更。那Fescar是如何解决这个问题呢答案就是 Fescar的全局写排它锁解决方案在全局事务A执行过程中全局事务B会因为获取不到全局锁而处于等待状态。 对于Fescar的隔离级别引用官方的一段话来作说明 全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。 在数据库本地隔离级别 读已提交 或以上的前提下Fescar 设计了由事务协调器维护的 全局写排他锁来保证事务间的 写隔离将全局事务默认定义在 读未提交 的隔离级别上。 我们对隔离级别的共识是绝大部分应用在 读已提交 的隔离级别下工作是没有问题的。而实际上这当中又有绝大多数的应用场景实际上工作在 读未提交 的隔离级别下同样没有问题。 在极端场景下应用如果需要达到全局的 读已提交Fescar 也提供了相应的机制来达到目的。默认Fescar 是工作在 读未提交 的隔离级别下保证绝大多数场景的高效性。 下面本文将深入到源码层面对Fescar全局写排它锁实现方案进行解读。Fescar全局写排它锁实现方案在TC(Transaction Coordinator)模块维护RM(Resource Manager)模块会在需要锁获取全局锁的地方请求TC模块以保证事务间的写隔离下面就分成两个部分介绍TC-全局写排它锁实现方案、RM-全局写排它锁使用
一、TC—全局写排它锁实现方案
首先看一下TC模块与外部交互的入口下图是TC模块的main函数
上图中看出RpcServer处理通信协议相关逻辑而对于TC模块真实处理器是DefaultCoordiantor里面包含了所有TC对外暴露的功能比如doGlobalBegin全局事务创建、doGlobalCommit全局事务提交、doGlobalRollback全局事务回滚、doBranchReport分支事务状态上报、doBranchRegister分支事务注册、doLockCheck全局写排它锁校验等其中doBranchRegister、doLockCheck、doGlobalCommit就是全局写排它锁实现方案的入口。
/**
* 分支事务注册在注册过程中会获取分支事务的全局锁资源
*/
Override
protected void doBranchRegister(BranchRegisterRequest request, BranchRegisterResponse response,RpcContext rpcContext) throws TransactionException {response.setTransactionId(request.getTransactionId());response.setBranchId(core.branchRegister(request.getBranchType(), request.getResourceId(), rpcContext.getClientId(),XID.generateXID(request.getTransactionId()), request.getLockKey()));
}
/**
* 校验全局锁能否被获取到
*/
Override
protected void doLockCheck(GlobalLockQueryRequest request, GlobalLockQueryResponse response, RpcContext rpcContext)throws TransactionException {response.setLockable(core.lockQuery(request.getBranchType(), request.getResourceId(),XID.generateXID(request.getTransactionId()), request.getLockKey()));
}
/**
* 全局事务提交会将全局事务下的所有分支事务的锁占用记录释放
*/
Override
protected void doGlobalCommit(GlobalCommitRequest request, GlobalCommitResponse response, RpcContext rpcContext)
throws TransactionException {response.setGlobalStatus(core.commit(XID.generateXID(request.getTransactionId())));
}
上述代码逻辑最后会被代理到DefualtCore去做执行 如上图不管是获取锁还是校验锁状态逻辑最终都会被LockManger所接管而LockManager的逻辑由DefaultLockManagerImpl实现所有与全局写排它锁的设计都在DefaultLockManagerImpl中维护。 首先就先来看一下全局写排它锁的结构
private static final ConcurrentHashMapString, ConcurrentHashMapString, ConcurrentHashMapInteger, MapString, Long LOCK_MAP new ConcurrentHashMap~(); 整体上锁结构采用Map进行设计前半段采用ConcurrentHashMap后半段采用HashMap最终其实就是做一个锁占用标记在某个ResourceId(数据库源ID)上某个Tabel中的某个主键对应的行记录的全局写排它锁被哪个全局事务占用。下面我们来看一下具体获取锁的源码
如上图注释整个acquireLock逻辑还是很清晰的对于分支事务需要的锁资源要么是一次性全部成功获取要么全部失败不存在部分成功部分失败的情况。通过上面的解释可能会有两个疑问
为什么锁结构前半部分采用ConcurrentHashMap,后半部分采用HashMap前半部分采用ConcurrentHashMap好理解为了支持更好的并发处理疑问的是后半部分为什么不直接采用ConcurrentHashMap而采用HashMap呢可能原因是因为后半部分需要去判断当前全局事务有没有占用PK对应的锁资源是一个复合操作即使采用ConcurrentHashMap还是避免不了要使用Synchronized加锁进行判断还不如直接使用更轻量级的HashMap。 为什么BranchSession要存储持有的锁资源这个比较简单在整个锁的结构中未体现分支事务占用了哪些锁记录这样如果全局事务提交时分支事务怎么去释放所占用的锁资源呢所以在BranchSession保存了分支事务占用的锁资源。 下图展示校验全局锁资源能否被获取逻辑
下图展示分支事务释放全局锁资源逻辑
以上就是TC模块中全局写排它锁的实现原理在分支事务注册时RM会将当前分支事务所需要的锁资源一并传递过来TC获取负责全局锁资源的获取要么一次性全部成功要么全部失败不存在部分成功部分失败在全局事务提交时TC模块自动将全局事务下的所有分支事务持有的锁资源进行释放同时为减少全局写排它锁获取失败概率TC模块对外暴露了校验锁资源能否被获取接口RM模块可以在在适当位置加以校验以减少分支事务注册时失败概率。
二、RM-全局写排它锁使用
在RM模块中主要使用了TC模块全局锁的两个功能一个是校验全局锁能否被获取一个是分支事务注册去占用全局锁全局锁释放跟RM无关由TC模块在全局事务提交时自动释放。分支事务注册前都会去做全局锁状态校验逻辑以保证分支注册不会发生锁冲突。 在执行Update、Insert、Delete语句时都会在sql执行前后生成数据快照以组织成UndoLog而生成快照的方式基本上都是采用Select...For Update形式RM尝试校验全局锁能否被获取的逻辑就在执行该语句的执行器中SelectForUpdateExecutor具体如下图 基本逻辑如下
执行Select ... For update语句这样本地事务就占用了数据库对应行锁其它本地事务由于无法抢占本地数据库行锁进而也不会去抢占全局锁。循环掌握校验全局锁能否被获取由于全局锁可能会被先于当前的全局事务获取因此需要等之前的全局事务释放全局锁资源如果这里校验能获取到全局锁那么由于步骤1的原因在当前本地事务结束前其它本地事务是不会去获取全局锁的进而保证了在当前本地事务提交前的分支事务注册不会因为全局锁冲突而失败。
注细心的同学可能会发现对于Update、Delete语句对应的UpdateExecutor、DeleteExecutor中会因获取beforeImage而执行Select..For Update语句进而会去校验全局锁资源状态而对于Insert语句对应的InsertExecutor却没有相关全局锁校验逻辑原因可能是因为是Insert那么对应插入行PK是新增的全局锁资源必定未被占用进而在本地事务提交前的分支事务注册时对应的全局锁资源肯定是能够获取得到的。
接下来我们再来看看分支事务如何提交对于分支事务中需要占用的全局锁资源如何生成和保存的。首先在执行SQL完业务SQL后会根据beforeImage和afterImage生成UndoLog与此同时当前本地事务所需要占用的全局锁资源标识也会一同生成保存在ContentoionProxy的ConnectionContext中如下图所示。
在ContentoionProxy.commit中分支事务注册时会将ConnectionProxy中的context内保存的需要占用的全局锁标识一同传递给TC进行全局锁的获取。
以上就是RM模块中对全局写排它锁的使用逻辑因在真正执行获取全局锁资源前会去循环校验全局锁资源状态保证在实际获取锁资源时不会因为锁冲突而失败但这样其实坏处也很明显在锁冲突比较严重时会增加本地事务数据库锁占用时长进而给业务接口带来一定的性能损耗。
三、总结
本文详细介绍了Fescar为在 读未提交 隔离级别下做到 写隔离 而实现的全局写排它锁包括TC模块内的全局写排它锁的实现原理以及RM模块内如何对全局写排它锁的使用逻辑。在了解源码过程中笔者也遗留了两个问题
全局写排它锁数据结构保存在内存中如果服务器重启/宕机了怎么办即TC模块的高可用方案是什么呢一个Fescar管理的全局事务和一个非Fescar管理的本地事务之间发生锁冲突怎么办具体问题如下图问题是全局事务A如何回滚
对于问题1有待继续研究对于问题2目前已有答案但Fescar目前暂未实现具体就是全局事务A回滚时会报错全局事务A内的分支事务A1回滚时会校验afterImage与当前表中对应行数据是否一致如果一致才允许回滚不一致则回滚失败并报警通知对应业务方由业务方自行处理。 #阿里云开年Hi购季#幸运抽好礼 点此抽奖https://www.aliyun.com/acts/product-section-2019/yq-lottery?utm_contentg_1000042901
原文链接 本文为云栖社区原创内容未经允许不得转载。
