你知道分布式事务的@GlobalLock注解是干什么的吗？

写隔离流程如下：
分支事务1-开始
|
V 获取 本地锁
|
V 获取 全局锁 分支事务2-开始
| |
V 释放 本地锁 V 获取 本地锁
| |
V 释放 全局锁 V 获取 全局锁
|
V 释放 本地锁
|
V 释放 全局锁
如上所示，一个分布式事务的锁获取流程：
1）先获取到本地锁，这样你已经可以修改本地数据了，只是还不能本地事务提交

2）而后，能否提交就是看能否获得全局锁

3）获得了全局锁，意味着可以修改了，那么提交本地事务，释放本地锁

4）当分布式事务提交，释放全局锁。这样就可以让其它事务获取全局锁，并提交它们对本地数据的修改了。
可以看到，这里有两个关键点

1）本地锁获取之前，不会去争抢全局锁

2）全局锁获取之前，不会提交本地锁

这就意味着，数据的修改将被互斥开来。也就不会造成写入脏数据。全局锁可以让分布式修改中的写数据隔离。

有的方法它可能并不需要@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校验全局锁，和之前在事务中的写隔离一样的逻辑。如果出现锁冲突的话进行重试操作~