Seata

org.apache.seata.core.model.ResourceManager

org.apache.seata.core.model.ResourceManagerInbound
主要是对内操作，接收TC发来的请求【提交分支事务、回滚分支事务】

主要是对外的操作，发送请求到TC【注册分支事务、上报分支状态、查询全局锁】

1. 获取分支事务类型
2. 获取资源管理器
3. 注册资源，通过RPC客户端注册资源，将当前的资源组ID和资源ID发给TC

org.apache.seata.rm.datasource.DataSourceProxy#getConnection()
通过目标数据源创建连接代理

org.apache.seata.rm.datasource.ConnectionProxy#commit
1、锁冲突重试机制：AT模式中RM发送创建分支事务请求到服务端，服务端会对分支涉及的行进行加锁
为了防止多个分布式事务兵法的修改相同行而造成数据冲突。如果发生冲突，则RM会通过LockRetryPolicy的execute()方法进行重试
2、分支事务提交
  a.注册分支事务 org.apache.seata.rm.datasource.ConnectionProxy#register
  b.保存事务的日志  org.apache.seata.rm.datasource.undo.AbstractUndoLogManager#flushUndoLogs, 把全局事务ID、分支事务ID、rollback_info（BLOB形式）、状态等字段存入undo_log表中
  c.本地事务提交
  d.上报分支事务状态【TC需要根据上报的事务状态来决定二阶段的处理】
3、查询Seata全局锁【for支持“读未提交”以上的隔离级别】
AT模式中，如果两个操作，创建订单&占用库存。如果一个分支事务提交之后创建订单成功，正在执行占用库存操作。那么此时另一个分支事务直接能看到这个订单，如果另一个分支事务是轮训订单执行推送，那么此时就会出现第一个分支占用库存失败-事务回滚，但是仍然被推送的情况。
所以，不断扫描的那个推送事务就应该利用Seata的全局锁，来实现“读已提交”的隔离级别
private void processLocalCommitWithGlobalLocks() throws SQLException {
        checkLock(context.buildLockKeys());
        try {
            targetConnection.commit();
        } catch (Throwable ex) {
            throw new SQLException(ex);
        }
        context.reset();
    }
先进性检查seata的全局锁，在进行本地事务的提交 org.apache.seata.rm.datasource.DataSourceManager#lockQuery

1. Statement用于执行静态的SQL语句，需要实现准备
2. PreparedStatement支持动态参数，比如 ？
3. PreparedStatement执行SQL，SQL会先被数据库解析和编译，然后放入命令缓冲区。执行同一个PreparedStatement对象，都会再次解析，但是不会再次编译，因为缓冲区有预编译的命令，并且可以重用
4. PreparedStatement减少编译次数，提高数据库性能
5. PreparedStatement有更好的安全性

1.SQL识别器 SQL识别器是通过Druid SQL识别器工厂创建的
org.apache.seata.sqlparser.druid.DruidSQLRecognizerFactoryImpl

2.SQL执行器org.apache.seata.rm.datasource.exec.BaseTransactionalExecutor#execute

通过数据源代理生成SQL识别器和SQL执行器，然后执行
1. 开启一个数据库本地事务
2. 查询前镜像
3. 执行SQL
4. 查询后镜像
5. 生成事务日志和事务锁数据
6. 注册分支事务
    - 如果注册成功，则分支提交成功，执行后续
    - 如果发生全局锁冲突，则回滚本地事务，在休眠一段时间之后，重新执行1-6
7. 提交本地事务
8. 向TC汇报分支状态

Seata AT模式二阶段 -- 提交

Seata AT模式二阶段 -- 回滚