所有文章
https://www.cnblogs.com/lay2017/p/12485081.html
正文
seata的at模式主要实现逻辑是数据源代理，而数据源代理将基于如MySQL和Oracle等关系事务型数据库实现，基于数据库的隔离级别为read committed。换而言之，本地事务的支持是seata实现at模式的必要条件，这也将限制seata的at模式的使用场景。
官方文档给出了非常好的图来说明at模式下，全局锁与隔离相关的逻辑：https://seata.io/zh-cn/docs/dev/mode/at-mode.html
写隔离
首先，我们理解一下写隔离的流程
分支事务1-开始 | V 获取 本地锁 | V 获取 全局锁 分支事务2-开始 | | V 释放 本地锁 V 获取 本地锁 | | V 释放 全局锁 V 获取 全局锁 | V 释放 本地锁 | V 释放 全局锁
如上所示，一个分布式事务的锁获取流程是这样的
1）先获取到本地锁，这样你已经可以修改本地数据了，只是还不能本地事务提交
2）而后，能否提交就是看能否获得全局锁
3）获得了全局锁，意味着可以修改了，那么提交本地事务，释放本地锁
4）当分布式事务提交，释放全局锁。这样就可以让其它事务获取全局锁，并提交它们对本地数据的修改了。
可以看到，这里有两个关键点
1）本地锁获取之前，不会去争抢全局锁
2）全局锁获取之前，不会提交本地锁
这就意味着，数据的修改将被互斥开来。也就不会造成写入脏数据。全局锁可以让分布式修改中的写数据隔离。
beforeImage校验全局锁
在将StatementProxy的时候我们提到过，在执行业务sql之前。会生成一个前置数据镜像，也就是beforeImage方法。
那么，beforeImage方法中将会生成一个 select [字段] from [表] where [条件] for update 这样的sql来查询镜像数据。seata的数据源代理将会对select for update这样的语句进行代理，代理中将会检验一下全局锁是否冲突，如下所示
while (true) { try { // 执行sql rs = statementCallback.execute(statementProxy.getTargetStatement(), args); // 构建数据行 TableRecords selectPKRows = buildTableRecords(getTableMeta(), selectPKSQL, paramAppenderList); // 构建锁KEY String lockKeys = buildLockKey(selectPKRows); if (StringUtils.isNullOrEmpty(lockKeys)) { break; } if (RootContext.inGlobalTransaction()) { // 校验全局锁 statementProxy.getConnectionProxy().checkLock(lockKeys); } else if (RootContext.requireGlobalLock()) { statementProxy.getConnectionProxy().appendLockKey(lockKeys); } else { throw new RuntimeException("Unknown situation!"); } break; } catch (LockConflictException lce) { if (sp != null) { conn.rollback(sp); } else { conn.rollback(); } // 锁冲突，重试 lockRetryController.sleep(lce); } }
如代码所示，select for update会做一次全局锁校验（checkLock会去调用Server端）。如果出现锁冲突，那么不断进行重试。
这样依赖，select for update所在的本地事务只要等待全局锁释放，由于已经占了本地锁，所以可以顺利获取全局锁。而后，进行入update等业务操作，然后提交顺利提交本地事务，
seata也表明，默认的事务隔离级别是read uncommitted。那么要实现read committed的话，就可以使用select for update来实现，逻辑和这里是一样的，其实就是通过占用本地锁，然后重试等待全局锁来达到读写隔离的目的。
分支事务register占用锁
在看分支事务register的时候，我们只是简单地扫了扫BranchSession的创建，然后添加到GlobalSession中。
这其中忽略了一个要点，就是在branch的register过程，会进行全局锁的获取操作。客户端会讲tablename和数据行的primary key给构造成lock key传输到Server端。而Server端将会根据这个lock key来判断是否能够占用全局锁
我们看看seata关于database方式的实现，跟进LockStoreDataBaseDao的acquireLock(List<LockDO> lockDOs)方法
方法很长，删减以后逻辑其实很简单。就是构造一个checkLock的sql，查查看是否已经有相关的数据。如果没有则进行doAcquireLock占用操作，占用操作也很简单就是进行数据插入。
前面checkLock提到的调用Server端的校验，其实也就是构造并执行一下checkLock看看有没数据而已
@Override public boolean acquireLock(List<LockDO> lockDOs) { // ... try { // ... // 获取checkLock的sql语句 String checkLockSQL = LockStoreSqls.getCheckLockableSql(lockTable, sj.toString(), dbType); ps = conn.prepareStatement(checkLockSQL); // ... // 查询是否有占用的数据 rs = ps.executeQuery(); String currentXID = lockDOs.get(0).getXid(); while (rs.next()) { String dbXID = rs.getString(ServerTableColumnsName.LOCK_TABLE_XID); if (!StringUtils.equals(dbXID, currentXID)) { canLock &= false; break; } // ... } if (!canLock) { conn.rollback(); return false; } // ... if (unrepeatedLockDOs.size() == 1) { LockDO lockDO = unrepeatedLockDOs.get(0); // 进行占用操作 if (!doAcquireLock(conn, lockDO)) { // ... } } else { // 进行占用操作 if (!doAcquireLocks(conn, unrepeatedLockDOs)) { // ... } } conn.commit(); return true; } catch (SQLException e) { // ... } finally { // ... } }
那么checkLockSql和doAcquireLock分开两个步骤是否会有并发问题呢？
理论上不会有的，正如我们前面一直提到的，要先获取本地锁，再来查询获取全局锁。所以，当本地锁还没有获取的时候，不会去获取全局锁。也就不需要考虑并发问题
如果占用全局锁失败怎么办呢？客户端会进行锁冲突的判断，然后进行重试操作。
分支事务释放全局锁
而分支事务在从GlobalSession中remove的时候会去unlock全局锁，如下GlobalSession中的代码
@Override public void removeBranch(BranchSession branchSession) throws TransactionException { for (SessionLifecycleListener lifecycleListener : lifecycleListeners) { lifecycleListener.onRemoveBranch(this, branchSession); } branchSession.unlock(); remove(branchSession); }
从unlock一路跟进LockStoreDataBaseDao的unlock(String xid, Long branchId)会看看
@Override public boolean unLock(String xid, Long branchId) { Connection conn = null; PreparedStatement ps = null; try { conn = logStoreDataSource.getConnection(); conn.setAutoCommit(true); // 批量删除的sql构造并执行 String batchDeleteSQL = LockStoreSqls.getBatchDeleteLockSqlByBranch(lockTable, dbType); ps = conn.prepareStatement(batchDeleteSQL); ps.setString(1, xid); ps.setLong(2, branchId); ps.executeUpdate(); } catch (SQLException e) { throw new StoreException(e); } finally { IOUtil.close(ps, conn); } return true; }
其实就是去删除之前doAcquireLock方法insert进去的数据，就算解锁了
@GlobalLock
有的方法它可能并不需要@GlobalTransactional的事务管理，但是我们又希望它对数据的修改能够加入到seata机制当中。那么这时候就需要@GlobalLock了。
加上了@GlobalLock，在事务提交的时候就回去checkLock校验一下全局锁。
private void processLocalCommitWithGlobalLocks() throws SQLException { // 全局锁校验 checkLock(context.buildLockKeys()); try { // 提交本地事务 targetConnection.commit(); } catch (Throwable ex) { throw new SQLException(ex); } context.reset(); }
可以看到，在本地事务提交之前会调用checkLock校验全局锁，和之前在事务中的写隔离一样的逻辑。也一样的，如果出现锁冲突的话进行重试操作
总结
本文简单看了几个全局锁的场景，可以感觉到只要遵循本地锁、全局锁的获取和释放的逻辑顺序，将数据读写的操作纳入seata的管理里面就可以基本做到维持数据一致性。