关于后端:PolarDBX-源码解读事务的一生

简介: 本文将次要解读 PolarDB-X 中事务局部的相干代码,着重解读事务的毕生在计算节点(CN)中的要害代码:从开始、执行、到最初提交这一整个生命周期。概述本文将次要解读 PolarDB-X 中事务局部的相干代码,着重解读事务的毕生在计算节点(CN)中的要害代码:从开始、执行、到最初提交这一整个生命周期。在浏览本文前,强烈推荐先浏览与 PolarDB-X 事务零碎相干的文章:PolarDB-X 强统一分布式事务原理PolarDB-X 分布式事务的实现(一)PolarDB-X 分布式事务的实现(二)InnoDB CTS 扩大PolarDB-X 分布式事务的实现(四):跨地区事务无处不在的 MySQL XA 事务以及此前公布的 PolarDB-X SQL 的毕生事务与连贯在 PolarDB-X 的 CN 层,与事务关系密切的是连贯。这是因为数据节点(DN)也具备单个 DN 内的事务能力,CN 则通过与 DN 的连贯来治理 DN 上的事务,从而实现强统一的分布式事务能力。其中波及到的连贯大抵如下图所示:

先简略说一下这外面波及的一些连贯。ServerConnection 相似于前端连贯,大部分的 SQL 语句执行的入口都是 ServerConnection#innerExecute。TConnection 中的 executeSQL 办法负责 SQL 语句的真正执行,也负责创立新的事务对象。TConnection 会始终援用着这个事务对象,直到事务提交或回滚。事务对象里有一个 TransactionConnectionHolder,负责管理该事务用到的所有物理连贯(CN 连贯 DN 的公有协定连贯)。值得一提的是,ExecutionContext 作为一条逻辑 SQL 执行的上下文,也会援用这个事务对象。这样,后续执行器须要应用物理连贯与 DN 通信时,就能够通过 ExecutionContext 拿到事务对象,再通过事务对象的 TransactionConnectionHolder 拿到适合的物理连贯。以上的各种连贯,都会在下文持续探讨。两个例子接下来,咱们以两个简略的例子,来阐明事务的毕生在 CN 的代码中是如何体现的。测试用表:CREATE TABLE tb1 (

`id` int PRIMARY KEY,
`a` int

) DBPARTITION BY HASH(id)先在外面插入几条数据:INSERT INTO tb1 VALUES (0, 0), (1, 1), (2, 2), (3, 3);测试应用的两个例子:– Example 1:
BEGIN;
SELECT * FROM tb1 WHERE id = 0;
UPDATE tb1 SET a = 100 WHERE id = 1;
COMMIT;– Example 2:
BEGIN;
SELECT * FROM tb1 WHERE id = 0;
UPDATE tb1 SET a = 101 WHERE id = 1;
UPDATE tb1 SET a = 101 WHERE id = 0;
COMMIT;留神到例 2 只比 例 1 多批改了 id = 1 的数据。测试表是按 id 拆分的,因而 id = 0 和 id = 1 的记录会落在不同的物理分片上(假如别离为分片 0 和分片 1)。例 1 读了分片 0,写了分片 1,而后提交了事务,这将会触发咱们对单分片写的“一阶段提交优化”。例 2 读了分片 0,随后写了分片 1 和 分片 0,而后提交了事务,这将会进行残缺的分布式事务提交流程。这两个例子还会触发“只读连贯优化”,即只有在第一次写的时候才真正开启分布式事务。在接下来的探讨中,咱们默认应用 TSO 事务策略和 RR 的隔离级别。例 1 事务的毕生BEGIN与 MySQL 相似,要开启一个事务,个别有两种形式。第一种形式是显式地执行 BEGIN 或 START TRANSACTION [transaction_characteristic],执行这两种语句,会调用 ServerConnection 中的 begin(boolean, IsolationLevel) 办法。第二种形式是执行 SET autocommit = 0,以后 session 会隐式开启事务,这种形式会调用 ServerConnection 中的 setAutocommit(boolean, boolean) 办法。两种形式都会调用 TConnection 的 setAutoCommit 办法。这些办法都只是简略地记录了一些变量(比方 transaction_characteristic 中设定的事务相干变量),同时标记这个连贯开启了事务。此时,事务对象也还没创立进去,也没有与后端连贯进行任何交互。读分片 0在开启事务后,执行 SELECT * FROM tb1 WHERE id = 0 时,才会真正创立事务对象。依据事务与连贯中的探讨,在 TConnection 中这条逻辑 SQL 的执行入口为 executeSQL,外面会真正创立事务对象,次要执行逻辑为(代码出自 PolarDB-X 5.4.12 release 版本,为了不便阐明,有删减及改变,下同):// TConnection#executeSQL(ByteString, Parameters, TStatement, ExecutionContext)
public ResultSet executeSQL(ByteString sql, Parameters params, TStatement stmt,

                            ExecutionContext executionContext) throws SQLException {

if (this.trx == null || this.trx.isClosed()) {

// 开启事务后,直到执行第一条语句,才会创立事务对象。
beginTransaction();

}
// 让 executionContext 援用 trx 对象,不便后续执行器通过 trx 对象拿物理连贯。
executionContext.setTransaction(this.trx);
resultCursor = executeQuery(sql, executionContext, trxPolicyModified);
}
// TConnection#beginTransaction(boolean)
private void beginTransaction(boolean autoCommit) {
// 依据一些默认的或用户设定的事务变量,抉择适合的事务策略,比方 TSO/XA 等。
trxPolicy = loadTrxPolicy(executionContext);
TransactionClass trxConfig = trxPolicy.getTransactionType(autoCommit, readOnly);
// 依据事务策略,创立出对应的事务对象。
this.trx = transactionManager.createTransaction(trxConfig, executionContext);
}在咱们的例子中,如果在上述代码打个断点,能够看到创立进去的是 TsoTransaction,其中一些值得关注的变量为:trx = {TsoTransaction}

// 此时还没有获取任何工夫戳。
snapshotTimestamp = -1
commitTimestamp = -1
// 事务写的第一个物理分片(下称主分片),事务日志将会写在这个分片上。
primaryGroup = null
// 该事务是否跨分片,如果是单分片事务,会优化为一阶段提交。
isCrossGroup = false
// 事务日志管理器,负责写事务日志。
globalTxLogManager = {GlobalTxLogManager}
// 分布式事务的 connectionHolder 都是 TransactionConnectionHolder,
// 外面别离存储了读写连贯,读连贯和写连贯在提交时行为会有所不同。
connectionHolder = {TransactionConnectionHolder}
    // 物理分片到对应写连贯的映射。
    groupHeldWriteConn = {HashMap}
    // 物理分片到对应读连贯汇合到映射。在 ShareReadView 优化开启时,
    // 能够同时存在多个读连贯和一个写连贯,因而这里读写连贯须要离开治理。
    // 该优化不在本文开展。
    groupHeldReadConns = {HashMap}在执行器阶段,会抉择给分片 0 下发一条 SELECT 语句,此时须要获取分片 0 的物理连贯,代码入口是 MyJdbcHandler 中的 getPhyConnection(ITransaction, ITransaction.RW, String, DataSource) 办法。其中的事务对象 Transaction 则是从 ExecutionContext 里拿到。该办法最初会调用 AbstractTransaction (这是所有分布式事务类的基类)中的 getConnection 办法。通过事务拿物理连贯的代码 AbstractTransaction#getConnection 如下:// AbstractTransaction#getConnection(String, String, IDataSource, RW, ExecutionContext)

public IConnection getConnection(String schema, String group, IDataSource ds, RW rw, ExecutionContext ec) {
if (/ 是事务的第一个写申请 /) {

// 把这个分片作为主分片,事务日志将写在这个分片上。
this.primaryGroup = group;
// 该分片还用于生成 XA 事务的 xid。
this.primaryGroupUid = IServerConfigManager.getGroupUniqueId(schema, group);

}
// 通过 connectionHolder 拿到物理连贯。
IConnection conn = connectionHolder.getConnection(schema, group, ds, rw);
if (/ 是写申请 / && !isCrossGroup && !this.primaryGroup.equals(group)) {

// 事务波及了多个分片。
this.isCrossGroup = true;

}
return conn;
}在咱们的例子中,上述参数 group 是物理分片 0,rw 是 READ,阐明须要物理分片 0 上的读连贯,ds 则次要用于生成物理连贯。因为咱们只是读申请,因而分片 0 不会作为主分片,会间接返回 connectionHolder.getConnection(schema, group, ds, rw) 的后果。通过连贯管理器拿物理连贯的代码 TransactionConnectionHolder#getConnection 如下:// TransactionConnectionHolder#getConnection(String, String, IDataSource, RW)
public IConnection getConnection(String schema, String group, IDataSource ds, RW rw) {
// 尝试获取该分片上的写连贯,如果有,间接返回这个写连贯。
HeldConnection groupWriteConn = groupHeldWriteConn.get(group);
if (groupWriteConn != null) {

return groupWriteConn.connection;

}

HeldConnection freeReadConn = / 尝试找到读连贯 /;
if (freeReadConn != null) {

if (/* 以后须要写连贯 */) {
  // 设置以后连贯为写连贯,participated = true 意味着该连贯是写连贯。
  freeReadConn.participated = true;
  this.groupHeldWriteConn.put(group, freeReadConn);
  // 因为本来是读连贯,这里才真正开启分布式事务。
  this.trx.commitNonParticipant(group, freeReadConn.connection);
  this.trx.begin(schema, freeReadConn.group, freeReadConn.connection);
}
return freeReadConn.connection;

}
// 以后分片没有任何连贯,创立一个新的连贯。还会依据读写类型,
// 设置好写连贯 groupHeldWriteConn 或读连贯汇合 groupHeldReadConns。
IConnection conn = new DeferredConnection(/ 这里会获取并封装该分片的公有协定连贯 /);
if (/ 须要写连贯 /) {

// 开启失常的分布式事务。
this.trx.begin(schema, group, conn);

} else {

// 优化为只读事务。
this.trx.beginNonParticipant(group, conn);

}
return conn;
}在咱们的例子中,因为是第一条语句,该分片上还没有任何连贯,因而会学生成一个连贯该分片的公有协定连贯,包装成 DeferredConnection,而后因为是读申请,会调用 beginNonParticipant 。TsoTransaction 的 beginNonParticipant 办法如下:// TsoTransaction#beginNonParticipant(String, IConnection)
protected void beginNonParticipant(String group, IConnection conn) throws SQLException {
if (snapshotTimestamp < 0) {

// 该事务从未拿过工夫戳,则在这里获取。
snapshotTimestamp = nextTimestamp();

}
// 应用公有协定的流水线执行机制执行 BEGIN。
conn.executeLater(“BEGIN”);
// 在 BEGIN 后发送工夫戳。
sendSnapshotSeq(conn);
}在咱们的例子中,公有协定连贯会流水线执行 BEGIN 语句(非阻塞,不等后果返回),且在稍后执行物理 SQL 时才发送工夫戳。至此,连贯上的一些初始化操作曾经实现,能够向执行器返回并执行读分片 0 的物理 SQL。写分片 1随后,咱们执行 UPDATE tb1 SET a = 100 WHERE id = 1。在执行器阶段,须要给分片 1 下发一条 UPDATE 语句,此时须要获取分片 1 的物理连贯,因而又会调用 AbstractTransaction#getConnection 办法,通过事务对象拿物理连贯。通过后面贴出的代码,咱们发现因为是事务的第一个写申请,因而分片 1 会视作主分片,用于生成 xid 和稍后记录事务日志。在获取物理连贯时,又会调用 TransactionConnectionHolder#getConnection 办法,通过连贯管理器拿物理连贯。通过后面贴出的代码,咱们发现因为分片 1 没有任何连贯,因而会生成一个公有协定连贯,包装成 DeferredConnection。与读分片 0 不同,因为是写申请,会执行 TsoTransaction 的 begin 办法。TsoTransaction 的 begin 办法如下:// TsoTransaction#begin(String, String, IConnection)
protected void begin(String schema, String group, IConnection conn) throws SQLException {
if (snapshotTimestamp < 0) {

// 该事务从未拿过工夫戳,则在这里获取。
snapshotTimestamp = nextTimestamp();

}
// 获取 xid。
String xid = getXid(group);
// 触发公有协定流水线执行 XA START。
conn.executeLater(“XA START ” + xid);
// 在 XA START 后发送工夫戳。
sendSnapshotSeq(conn);
}简略来说,和此前 beginNonParticipant 办法惟一的区别在于,应用了 XA START 开启事务。依据 MySQL 对于 XA 事务的阐明,xid 由 gtrid [, bqual [, formatID ]] 组成,这里的 gtrid 是“drds-事务 id @主分片Uid”,这样保障了同一个事务在不同分片上执行 XA START,会应用雷同的 gtrid。bqual 设置以后连贯的分片,用于在事务复原时确定分支事务所在的分片。 在咱们的例子中,xid 为:’drds-13e101d74e400000@5ae6c3b5be613cd1′, ‘DB1_000001_GROUP’,其中 13e101d74e400000 是事务 id,5ae6c3b5be613cd1 是分片 1 的 Uid,DB1_000001_GROUP 是分片 1 的具体分片名称。值得注意的是,这里会把之前的工夫戳发送到分片 1。至此,连贯上的一些初始化操作曾经实现,能够向执行器返回并执行写分片 1 的物理 SQL。COMMIT最初,执行 COMMIT 提交事务。解决 COMMIT 的代码入口为 ServerConnection#commit(),其次要调用了 TConnection#commit 办法,代码如下:// TConnection#commit()
public void commit() throws SQLException {
try {

// 触发事务的提交流程。
this.trx.commit();

} finally {

// 大部分状况下,如果事务提交胜利,或出现异常后正确处理了,
// 所有连贯会被敞开并开释,trx.close() 相当于什么也不做。
// 但如果事务提交失败且没有解决,这里会回滚事务并开释所有物理连贯。
this.trx.close();
// 去掉对这个事务对象的援用,意味着以后连贯里这个事务毕生的完结。
this.trx = null;

}
}咱们重点关注一下事务的提交流程,上述 this.trx.commit() 调用时,会调用 ShareReadViewTransaction(该类继承了 AbstractTransaction,基于 XA 事务实现了共享 readview 的性能,XATransaction 和 TsoTransaction 都会继承这个类,在这里能够简略了解为 XA 事务的基类)的 commit 办法,代码如下:// ShareReadViewTransaction#commit()
public void commit() {
if (!isCrossGroup) {

// 如果只波及了单个分片的写,进行一阶段提交优化。
commitOneShardTrx();

} else {

// 失常的多分片分布式事务提交流程。
commitMultiShardTrx();

}
}在咱们的例子中,因为只写了分片 1,所以进入一阶段提交优化,代码如下:// ShareReadViewTransaction#commitOneShardTrx()
protected void commitOneShardTrx() {
// 对持有的所有物理连贯执行以下流程,以提交每个物理连贯开启的事务。
forEachHeldConnection((group, conn, participated) -> {

  if (!participated) {
    // 只读连贯是 BEGIN 开启事务的,且只有读操作,执行 ROLLBACK 即可。
    conn.execute("ROLLBACK");
  } else {
    // 获取 xid。
      String xid = getXid(group);
    // 写连贯是 XA START 开启事务的,执行 XA END 和 XA COMMIT ONE PHASE 提交事务。
    conn.execute("XA END " + xid + "; XA COMMIT " + xid + " ONE PHASE");
  }

});
// 所有连贯都提交了分支事务,开释并清空这些物理连贯。
connectionHolder.closeAllConnections();
}咱们一共持有了 2 个物理连贯。对于分片 0 的只读连贯,会间接执行 ROLLBACK;对于分片 1 的写连贯,则执行 XA END 和 XA COMMIT ONE PHASE 提交事务。留神到咱们并没有获取 commit timestamp,因为在一阶段提交优化里,commit timestamp 会由 InnoDB 计算生成:具体的计算规定是:COMMIT_TS = MAX_SEQUENCE + 1,其中 MAX_SEQUENCE 为 InnoDB 本地保护的历史最大的 snapshot_ts。如果提交失败了,会调用事务的 close 办法,代码如下:// AbstractTransaction#close()
public void close() {
// 回滚所有物理连贯上的事务。
cleanupAllConnections();
// 开释并清空这些物理连贯。
connectionHolder.closeAllConnections();
}值得一提的是,cleanupAllConnections() 也是 ROLLBACK 语句次要调用的办法。因而为了同时理解 ROLLBACK 语句执行流程,咱们也看一下 cleanupAllConnections 办法的代码:// AbstractTransaction#cleanupAllConnections()
protected final void cleanupAllConnections() {
// 对持有的所有物理连贯执行以下流程,以回滚每个物理连贯开启的事务。
forEachHeldConnection((group, conn, participated) -> {

if (conn.isClosed()) { return; }
if (!participated) {
  // 只读连贯是 BEGIN 开启事务的,且只有读操作,执行 ROLLBACK 即可。
  conn.execute("ROLLBACK");
} else {
  // 获取 xid。
    String xid = getXid(group);
  // 写连贯是 XA START 开启事务的,执行 XA END 和 XA ROLLBACK 回滚事务。
  conn.execute("XA END " + xid + "; XA ROLLBACK " + xid);
}

});
}能够看到,回滚的逻辑是看状况执行 ROLLBACK 或 XA ROLLBACK 来回滚事务的。至此,咱们看到了例 1 事务的毕生。接下来看一下多分片写的事务流程。例 2 事务的毕生写分片 0例 2 中,从开启事务到执行 UPDATE tb1 SET a = 100 WHERE id = 1 走的流程和例 1 一样,直到执行 UPDATE tb1 SET a = 100 WHERE id = 0 时,才有所不同。具体而言,事务在之前就获取了分片 0 的只读连贯,当执行到 TransactionConnectionHolder#getConnection 时,会先提交只读连贯上的事务(理论执行了 ROLLBACK),而后在这条连贯上用 XA START 开启 XA 事务,设置好工夫戳,就能够把这个物理连贯返回给执行器,最终执行物理 SQL。因为这是第二个写连贯,因而还会设置事务为跨分片事务,以触发失常的两阶段提交流程。COMMIT例 2 的重点在于写了 2 个分片,因而 COMMIT 时会调用 commitMultiShardTrx() 走多分片的分布式提交流程。办法 commitMultiShardTrx 代码如下:// TsoTransaction#commitMultiShardTrx()
protected void commitMultiShardTrx() {
// 事务日志的提交状态,一共有 3 种:FAILURE,UNKNODWN,SUCCESS。
TransactionCommitState commitState = TransactionCommitState.FAILURE;
try {

// 对所有连贯执行 XA prepare。
prepareConnections();
// 拿 commit 工夫戳。
commitTimestamp = nextTimestamp();
Connection logConn = /* 获取主分片上的连贯 */;
// 所有分支事务 prepare 胜利,在写事务日志前,状态设置为 UNKNOWN,其作用见后续代码阐明。
commitState = TransactionCommitState.UNKNOWN;
// 写事务日志。
writeCommitLog(logConn);
// 写事务日志胜利,状态置为 SUCCESS。
commitState = TransactionCommitState.SUCCESS;

} catch (RuntimeException ex) {

exception = ex;

}
if (commitState == TransactionCommitState.FAILURE) {

// 写事务日志前失败了,回滚所有连贯。
rollbackConnections();

} else if (commitState == TransactionCommitState.SUCCESS) {

// 写事务日志胜利了,提交所有连贯。
commitConnections();

} else {

// 所有连贯都 prepare 胜利了,但无奈确定是否写入了事务日志,
// 将由事务复原的逻辑来决定是 COMMIT 还是 ROLLBACK。这里先抛弃所有连贯。
discardConnections();

}

// 开释并清空这些物理连贯。
connectionHolder.closeAllConnections();

// prepare 或 commit 阶段抛出的异样,这里从新抛出。
if (exception != null) {

  throw exception;

}
}折叠 上述代码正是两阶段提交的流程。在 prepare 阶段,调用 prepareConnections(),其中对只读连贯只是简略执行 ROLLBACK 语句;对于写连贯,执行 XA END {xid} 和 XA PREPARE {xid} 语句。如果所有连贯都 prepare 胜利了,在 commit 阶段,调用 writeCommitLog(logConn),用主分片(在咱们的例子中,是分片 1)的连贯,写下事务日志,次要包含了事务的 id 和 commit 工夫戳,事务日志次要用于后续的事务复原。如果事务日志写胜利了,就意味着 commit 胜利了,会调用 commitConnections() 对所有连贯进行提交,这一步只用对写连贯设置 commit 工夫戳 SET innodb_commit_seq = {commitTimestamp} 和执行 XA COMMIT {xid} 语句。如果在写事务日志前失败了,会调用 rollbackConnections() 对所有连贯进行回滚,次要会对写连贯执行 XA ROLLBACK {xid} 回滚。如果无奈确定是否胜利写入了事务日志,事务的状态会是 UNKNOWN。此时,咱们能确定所有分支事务都胜利 prepare 了,如果事务日志写入胜利了,则要进行 XA COMMIT;如果事务日志没有写入,则要进行 XA ROLLBACK。因为不确定是要提交还是回滚,咱们会抛弃所有物理连贯,使这些连贯后续不再可用。至于事务最终是提交还是回滚,则交给事务复原线程来解决,接下来咱们会解读事务复原相干的代码。事务复原一个分布式事务在提交的时候,可能遇到各种状况导致提交失败。例如,所有分支事务都 prepare 胜利了,事务日志也写入胜利了,但 XA COMMIT 失败了。对于这种状况,事务复原时须要正确提交所有分支事务。另一种状况是,局部分支事务 prepare 胜利了,另外一些失败了,或事务日志没有写入胜利。对于这种状况,事务复原须要回滚掉已 prepare 的分支事务。事务复原次要由 XARecoverTask 负责。其主体代码为 recoverInstance 办法,该办法查看一个 DN 下的所有 prepare 过的事务,并依据事务状态提交或回滚这些事务,代码如下:// XARecoverTask#recoverInstance(IDataSource, Set<String>)
// dataSource 用户获取 DN 的连贯,groups 是以后逻辑库的所有物理分片
private void recoverInstance(IDataSource dataSource, Set<String> groups) {
// 执行 XA RECOVER 获取该 DN 上所有 prepare 的事务。
// 此处省略了从 dataSource 获取连贯和生成 statement 的代码。
ResultSet rs = stmt.executeQuery(“XA RECOVER”);
while (rs.next()) {

// 对每一条记录,生成对象 PreparedXATrans,
// 次要包含 xid,事务id,分支事务所在的分片,主分片等信息。
PreparedXATrans trans = /* 从 rs 中获取一行数据生成 */;
if (/* trans 所在分片是以后逻辑库的一个物理分片 && 
    trans 在上一次 recover 工作时也呈现过,
    即较长时间都未被提交或回滚*/) {
  // 染指解决这个分支事务:回滚或提交。
  rollBackOrForward(trans, stmt);
}

}
}该工作每 5 秒到每个 DN 上执行一次 XA RECOVER,失去所有 prepare 过的事务,如果看到一个事务在上一次工作中也呈现过,即至多过来 5 秒都没有提交或回滚,则会抉择对这个事务进行回滚或提交。相干逻辑代码为 rollBackOrForward,代码如下:// XARecoverTask#rollBackOrForward(PreparedXATrans, Statement)
private boolean rollBackOrForward(PreparedXATrans trans, Statement stmt) throws SQLException {
String primaryGroup = / 从 trans 里解析出主分片,详见前文对于 xid 的生成 /;
// 尝试从主分片的事务日志中找到相干的事务日志。
GlobalTxLog tx = GlobalTxLogManager.get(primaryGroup, trans.transId);
if (tx != null) {

// 的确存在事务日志,依据事务日志状态判断回滚或提交。
if (tx.getState() == TransactionState.ABORTED) {
  // ABORTED 状态的事务须要回滚。
  return tryRollback(stmt, trans);
} else {
  // SUCCESS 状态的事务须要提交。
  return tryCommitTSO(stmt, trans, tx.getCommitTimestamp());
}

} else {

// 没有找到事务日志,尝试回滚,先开启事务,写下事务日志,标记事务为 ABORTED。
try (Connection conn2 = /* 获取主分片上的另一个连贯 */;) {
  conn2.setAutocommit(false);
  // 尝试回滚,如果因为别的线程正在解决这个事务
  //(比方该事务只是提交得慢,连贯仍未断开,还在提交流程)
  // 而报错,就回滚上一条写事务日志的语句。
  txLog.append(transInfo.transId, TransactionType.XA, TransactionState.ABORTED, new ConnectionContext(), conn2);
  stmt.execute("XA ROLLBACK " + trans.toXid());
  conn2.commit();
  return true;
} catch (Exception e) {
  /* 依据异样判断是否要回滚写事务日志的操作 */
}

}
}该办法次要有 3 段逻辑。一是如果存在对应的事务日志,且事务状态是 ABORTED,那就执行 tryRollback 办法回滚,该办法次要执行了 XA ROLLBACK {xid}。二是如果事务状态是 SUCCESS,那就执行 tryCommitTSO 办法回滚,该办法会设置 commit 工夫戳,而后执行 XA COMMIT {xid}。三是如果没找到事务日志,此时个别有两种可能:1)事务提交失败了,且没写下事务日志,此时须要回滚;2)事务还在两阶段提交的流程中,只是 prepare 较慢,还没开始写事务日志,此时不须要做任何操作。在 MySQL 中,如果发动 XA START 的连贯没有敞开,其余连贯是无奈通过 XA ROLLBACK 或 XA COMMIT 来回滚或提交这个分支事务的。咱们利用这一个性,首先在事务日志插入一条 ABORTED 记录,表明这个分布式事务须要回滚,而后尝试执行 XA ROLLBACK 回滚这个分支事务。如果遇到 2)的状况,则会收到特定的报错,此时再回滚掉插入 ABORTED 事务日志的操作。在咱们插入 ABORTED 事务日志后,本来正在提交事务的线程在插入 SUCCESS 事务日志时会被阻塞,而在咱们回滚掉插入 ABORTED 事务日志的操作后,事务提交流程就会持续进行上来。小结本文次要解读了 PolarDB-X 中 CN 端的事务相干的代码,以 TSO 事务为主,应用两个例子,一步步地展现了事务的开启、执行、提交、复原等流程。心愿大家浏览本文后,能更加理解 PolarDB-X 的事务零碎。原文链接:http://click.aliyun.com/m/100…本文为阿里云原创内容,未经容许不得转载。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据