Seata：事务隔离机制
一、前言
什么是事务隔离机制？
我们日常在使用数据库时，总会碰见它，它是为了解决并发情况下保持数据一致性的问题。
二、设计原理
对于隔离性，Seata 官方给出一段话：全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。
我们对隔离级别的共识是：微服务场景产生的分布式事务，绝大部分应用在度已提交的隔离级别下工作是没有问题的。而实际上，这当中又有绝大多数的应用场景，实际上工作在读未提交的隔离级别下同样没有问题。
默认情况下，Seata 是工作在读未提交的隔离级别下，保证绝大多数场景的高效性。
那么，在读未提交的隔离级别下，如果没有采取任何其他手段，将会出现很严重的问题，比如：
如上图所示，最终 全局事务A 对 资源R1 应该回滚到哪种状态？
很明显，如果再根据 UndoLog 去做回滚，就会发生严重问题：覆盖了 全局事务B 对 资源R1 的变更。
那 Seata 是如何解决这个问题的呢？
在数据库本地隔离级别读已提交或以上的前提下，Seata 设计了由事务协调器维护的全局写排它锁，来保证事物间的写隔离，将全局事务默认定义在读未提交的隔离级别上。
在极端场景下，应用如果需要达到全局的读已提交，Seata 也提供了相应的机制来达到目的。
即是，全局事务未提交，但本地已提交的数据，对其他全局事务是可见的，但其他全局事务不能操作该条数据，必须等当前全局事务提交。
举个例子，产品份额有 5W，A 用户买了 2W，份额Branch一阶段完毕（本地事务份额已经扣除 Commit），但是在下单的时候异常了。因为本地事务读已提交，这时候 Seata 允许业务访问该条数据 3W，在 A 用户的份额Branch未回滚成功前，对其他用户可见，但其他用户并不能购买该产品，必须等到产品份额回滚到 5W，其他用户才可以操作产品数据。
三、源码分析
Seata 全局写排它锁 实现是在 TC 模块维护，RM 模块会在需要获取全局锁的地方请求 TC 模块以保证事物间的写隔离。
1、RM 在提交本地事务之前，向 TM 注册分支事务，并尝试获取全局锁
private void processGlobalTransactionCommit() throws SQLException {
try {
//向 TM 注册分支事务
register();
} catch (TransactionException e) {
//获取全局锁失败，抛出异常
recognizeLockKeyConflictException(e, context.buildLockKeys());
}
//省略部分代码...
}
private void register() throws TransactionException {
Long branchId = DefaultResourceManager.get().branchRegister(BranchType.AT, getDataSourceProxy().getResourceId(),
null, context.getXid(), null, context.buildLockKeys());
context.setBranchId(branchId);
}
public Long branchRegister(BranchType branchType, String resourceId, String clientId, String xid, String applicationData, String lockKeys) throws TransactionException {
//省略 try ... catch ... 和其他部分代码...
BranchRegisterRequest request = new BranchRegisterRequest();
request.setXid(xid);
request.setLockKey(lockKeys);
request.setResourceId(resourceId);
request.setBranchType(branchType);
request.setApplicationData(applicationData);
BranchRegisterResponse response = (BranchRegisterResponse) RmRpcClient.getInstance().sendMsgWithResponse(request);
if (response.getResultCode() == ResultCode.Failed) {
throw new RmTransactionException(response.getTransactionExceptionCode(), String.format("Response[ %s ]", response.getMsg()));
}
return response.getBranchId();
}
2、TC 在接收到 RM 的注册请求后，会获取分支事务的全局锁资源
//分支事务注册，在注册过程中会获取分支事务的全局锁资源
protected void doBranchRegister(BranchRegisterRequest request, BranchRegisterResponse response,
RpcContext rpcContext) throws TransactionException {
response.setBranchId(
core.branchRegister(request.getBranchType(), request.getResourceId(), rpcContext.getClientId(),
request.getXid(), request.getApplicationData(), request.getLockKey()));
}
上述代码逻辑最后会被代理到DefualtCore去做执行。
public Long branchRegister(BranchType branchType, String resourceId, String clientId, String xid,
String applicationData, String lockKeys) throws TransactionException {
GlobalSession globalSession = assertGlobalSessionNotNull(xid);
return globalSession.lockAndExcute(() -> {
//省略部分代码...
//创建全局分支事务会话
BranchSession branchSession = SessionHelper.newBranchByGlobal(globalSession, branchType, resourceId,
applicationData, lockKeys, clientId);
//尝试获取分支事务全局锁资源，没有拿到则抛出异常
if (!branchSession.lock()) {
throw new BranchTransactionException(LockKeyConflict,
String.format("Global lock acquire failed xid = %s branchId = %s", globalSession.getXid(), branchSession.getBranchId()));
}
return branchSession.getBranchId();
});
}
public boolean lock() throws TransactionException {
//从工厂获取锁管理器，获取锁
return LockerFactory.getLockManager().acquireLock(this);
}
上述，不管是获取锁，还是检验锁状态逻辑，最终都会被LockManager所接管，而LockManager的逻辑由DefaultLockManager实现，所有与全局写排它锁的设计都在DefaultLockManager中维护。
引用
官方文档 - 隔离性
官方文档 - AT模式
https://www.jianshu.com/p/4cb127b737cf
https://yq.aliyun.com/articles/689494?utm_content=g_1000040676