一、概述

介绍了与悲观协调有关的各个数据结构之后，接下来将介绍一个 DM 系统从接受到第一条分表 DDL 开始，到所有该 DDL 对应的 Lock resolved 的全过程。

本节内容皆参考 DM v6.0，对现在而言，有可能已过时，欢迎大家提出意见～

二、Overview

假设现在起了 master 和两个 Worker，两个 Worker 分别绑定两个 Source（s1，s2），每个 Source 有两个分表（t1，t2），这四个表会 route 到一个 target table（tarTbl）中。在 DDL 到来之前，两个 worker 会创建好 ShardingGroupKeeper，里面只有一个 target table，两个 source table。

两个 Worker 先后收到两个 Source 四个分表的同一条 DDL，表示为：

DDL1：表示对 s1.t1 的 DDL。

DDL2：表示对 s2.t1 的 DDL。

DDL3：表示对 s1.t2 的 DDL。

DDL4：表示对 s2.t2 的 DDL。

三、具体过程

本小节 worker 对 DDL 的处理从 handleQueryEventPessimistic 开始，如果不知道在此之前的 DDL 做过哪些处理，请期待后续文章😁

接下来将对上图中的步骤一一介绍

Step 1

worker1 收到来自 source1 的 DDL1，会直接 TrySync，这里返回了一大堆的参数，其实有用的就只是 synced，简单来说，里面只做了一件事：AddItem。下面详细介绍一下 TrySync

本节，假设该 DDL 不是 CreateTableStmt，如果是的话，也很简单，每次都是 remain <=0，synced = true，但是只有第一次发送该 create table 的 worker 会 syncDDL。

TrySync

想要知道 worker 在悲观协调的时候做了什么，必须要搞懂 TrySync 是怎么运作的。在此之前，我们来重新理解一下 ShardingGroupKeeper：

单独拿出一个 ShardingGroup 举例（颜色代表 DDL 的种类）：

Example

worker 收到了以下 DDL

依次收到了 table1 橙色、黄色、绿色三条 DDL

收到了 table2 橙色

这个时候 activeIdx = 0，remain = 1，因为只有 table3 没有收到 active DDL 了

如果在这个时候收到了 table3 橙色 DDL，remain = 0，处理了这条 DDL 之后，active ++

如果这个时候收到 table2 绿色 DDL，则会报错，悲观协调要求同一个 source table 中 DDL 必须有序

如果 group 中所有的 DDL 都 resolved 了。则会重置一下 meta

总结：AddItem 就是上面图中把 DDLItem 放进 ShardingSequence 的过程

Step 2 与 Step 1 相同

Step 3

由于 tarTbl 只有两个 source table：s1.t1 和 s1.t2，这时 TrySync 后，synced = true，说明该 worker ready

Step 4

worker1

PutInfo：发送 ready info 给 master（后面会详细介绍这个函数）

之后会被阻塞，等待 master 发送 operation。

Master

watchInfoPut：成功监听到了

handleInfoPut：master 也开始 TrySync，master 的 TrySync 相比 worker 中的要简单很多，每一个 Info 直接相当于该 source/worker 已 ready，所以直接统计是否所有 ready 即可

由于这里是第一个 worker 发 info 给 master，所以需要新建 Lock，新建 Lock 过程中会获取该 task 所有的 source，并存到 lock 中，这样就知道还有多少 source 没 ready。显然还有 source2 没 ready。

继续等待

Step 5 与 Step 3 相同

Step 6

前面与 Step 4 相同，但是这时所有 source 都 ready 了，synced = true

Step 7

master

putOpForOwner：发送 exec operation to owner(worker1)

Worker1

得到 master 的 exec operation

NewDDLJob 并 handle

addJob：发送 job 给 DDLJobCh

syncDDL：之前 worker 起的协程接受到该 job

拿到刚刚得到的 operation，并且不会被跳过，因为 ignore = false

Step 8

同步到下游

Step 9

Worker1

DoneOperationDeleteInfo：发送 done operation 给 master 并删除 info

Step 10

Master

接受 done operation

markDone

putOpsForNonOwner：给其他所有 non-owner 发送 skip info（skip done 是为了防止把 done 覆盖掉）

Worker2

接受到了 no exec(skip) 的 operation，和 Step 7 类似，但是在 syncDDL 的时候会被 skip

Step 11 和 Step 9 相同

四、总结

本节介绍了在悲观协调过程中，遇到第一条 DDL 语句，生成 Lock，到收到所有 DDL 语句，Lock 解除的过程。

经过本节的学习，我们已经完全学会了 DM 悲观协调的过程。是不是也没那么复杂😏，但是在这个过程中，我们只知道 DDL 的处理方式，这个过程中的 DML 会怎么办呢？下一章揭晓。

五、疑似 bug

initShardingGroups 中对 ShardingGroup.sources 进行了初始化，这里包含了该 targetTable 对应的所有 sourceTables

在 TrySync 的时候，却使用第一个 sourceTable[0]，来标记所有的 DDL[]，如果 len(DDL[]) != 1，则 remain 永远不可能为 0。因为 sourceTables 来源于 ddlInfo。而 DDLInfo 只存了第一条 ddl 的 ddlInfo，实际上对于每一个 Split 之后的 DDL，都会 genDDLInfo。

但是奇怪的是，代码中标注了不支持 multi-table DDL，这个 error 在 pessimist/optimist mode 中都用到了。但是在现在看 pessimist 代码中，又看到其为 multi-table DDL 实现了部分相关逻辑。。。有毒

比如：

https://github.com/pingcap/tiflow/blob/release-6.0/dm/syncer/syncer.go#L2957-L2960

https://github.com/pingcap/tiflow/blob/release-6.0/dm/syncer/sharding-meta/shardmeta.go#L35

。。。