## 內容概要

TiCDC 是一款 TiDB 增量資料同步工具，透過拉取上游 TiKV 的資料變更日誌，TiCDC 可以將資料解析為有序的行級變更資料輸出到下游。

本文是 TiCDC 原始碼解讀的第二篇，將於大家介紹 TiCDC 的重要組成部分，TiKV 中的 CDC 模組。我們會圍繞 4 個問題和 2 個目標展開。

1. TiKV 中的 CDC 模組是什麼？
2. TiKV 如何輸出資料變更事件流？
3. 資料變更事件有哪些？
4. 如何確保完整地捕捉分散式事務的資料變更事件？

希望在回答完這4個問題之後，大家能：

- ? 瞭解資料從 TiDB 寫入到 TiKV CDC 模組輸出的流程。
- ?️ 瞭解如何完整地捕捉分散式事務的資料變更事件。

在下面的內容中，我們在和這兩個目標相關的地方會標記上 ? 和 ?️，以便提醒讀者留意自己感興趣的地方。

## TiKV 中的 CDC 模組是什麼？

### CDC 模組的形態

從程式碼上看，CDC 模組是 TiKV 原始碼的一部分，它是用 rust 寫的，在 TiKV 程式碼庫裡面；從執行時上看，CDC 模組執行在 TiKV 程式中，是一個執行緒，專門處理 TiCDC 的請求和資料變更的捕捉。

### CDC 模組的作用

CDC 模組的作用有兩個：

1. 它負責捕捉實時寫入和讀取歷史資料變更。這裡提一下歷史資料變更指已經寫到 rocksdb 裡面的變更。
2. 它還負責計算 resolved ts。這個 resolved ts 是 CDC 模組裡面特有的概念，形式上是一個 uint64 的 timestamp。它是 TiKV 事務變更流中的 perfect watermark，perfect watermark 的詳細概念參考《Streaming System》的第三章，我們可以用 resolved ts 來告知下游，也就是 TiCDC，在 tikv 上所有 commit ts 小於 resolved ts 事務都已經完整傳送了，下游 TiCDC 可以完整地處理這批事務了。

### CDC 模組的程式碼分佈

CDC 模組的程式碼在 TiKV 程式碼倉庫的 `compoenetns/cdc` 和 `components/resolved_ts` 模組。我們在下圖中的黑框裡面用紅色標註了幾個重點檔案。

在 `delegate.rs` 檔案中有個同名的 `Delegate` 結構體，它可以認為是 Region 在 CDC 模組中的“委派”，負責處理這個 region 的變更資料，包括實時的 raft 寫入和歷史增量資料。

在 `endpoint.rs` 檔案中有個 `Endpoint` 結構體，它執行在 CDC 的主執行緒中，驅動整個 CDC 模組，上面的 delegate 也是執行在整個執行緒中的。

`initializer.rs` 檔案中的 `Initializer` 結構體負責增量掃邏輯，同時也負責 delegate 的初始化，這裡的增量掃就是讀取儲存在 rocksdb 中的歷史資料變更。

`service.rs` 檔案中的 `Service` 結構體，它實現了 ChagneData gRPC 服務，執行在 gRPC 的執行緒中，它負責 TiKV 和 TiCDC 的 RPC 互動，同時它和 `Endpoint` 中的 `Delegate` 和 `Initializer` 也會有互動，主要是接受來自它倆的資料變更事件，然後把這些事件透過 RPC 傳送給 TiCDC。

最後一個重要檔案是 `resolver.rs`，它與上面的檔案不太一樣，在 resolve_ts 這個 component 中，裡面的 `Resolver` 負責計算 resolved ts。

![1.PNG](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/1_e91f78042c.PNG)

## TiKV 如何輸出資料變更事件流？

我們從端到端的角度完整地走一遍資料的寫入和流出。下圖概括了資料的流動，我們以資料儲存到磁碟為界，紅色箭頭代表資料從 TiDB 寫入 TiKV 磁碟的方向，藍色箭頭代表資料從 TiKV 磁碟流出到 TiCDC 的方向。

![UML 圖.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_bb75620add.jpg)

### TiDB -> TiKV Service
 
- txn prewrite: [Tikv::kv_prewrite(PrewriteRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/server/service/kv.rs#L242)
- txn commit: [Tikv::kv_commit(CommitRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/server/service/kv.rs#L263)

我們看下從 TiDB 指向 TiKV 的紅線。我們知道資料來自 TiDB 的事務寫入，對於一個正常的事務來說，TiDB 需要分兩次呼叫 TiKV 的 gRPC 介面，分別是 kv_prewrite 和 kv_commit，對應了事務中的 prewrite 和 commit，在 request 請求中包含了要寫入或者刪除的 key 和它的 value，以及一些事務的後設資料，比如 start ts，commit ts 等。

### TiKV Service -> Txn

- txn prewrite: [Storage::sched_prewrite(PrewriteRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/server/service/kv.rs#L2189-L2241)
- txn commit: [Storage::sched_commit(CommitRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/server/service/kv.rs#L2271-L2283)

我們再看從 gRPC 指向 Txn 的紅線。它代表 RPC 請求從 gRPC 模組流到事務模組的這一步。這裡相應的也有兩個 API 的呼叫，分別是 `sched_prewrite` 和 `sched_commit`，在這兩個 API 中，事務模組會對 request 做一些檢查，比如檢查 write conflict，計算 commit ts 等（事務的細節可以參考 TiKV 的原始碼閱讀文章，在這裡就先跳過了。）

### Txn -> Raftstore

- txn prewrite: [Engine::async_write_ext(RaftCmdRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/storage/txn/scheduler.rs#L1323)
- txn commit: [Engine::async_write_ext(RaftCmdRequest)](https://github.com/tikv/tikv/blob/v6.4.0/src/storage/txn/scheduler.rs#L1323)

事務模組到 Raftstore 的紅線代表：Request 透過檢查後，會被事務模組序列化成對 KV 的操作，然後被組裝成 `RaftCmdRequest`。`RaftCmdRequest` 再經由 `Engine::async_commit_ext API` 被髮送至 Raftstore 模組。

大家可以看到 prewrite 和 commit 都是變成了 `RaftCmdRequest`，也都是透過 `Engine::async_commit_ext` 傳送到 Raftstore 模組的。這說明了什麼呢？它說明了到 Engine 這一層，TiDB 的請求中的事務資訊已經被“抹去”了，所有的事務資訊都存到了 key 和 value 裡面。

Raftstore 模組會將這些 key value 提交到 Raft Log 中，如果 Raft Log Commit 成功，Apply 執行緒會將這些 key 和 value 寫入到 Rocksdb。（這裡面的細節可以參考 [TiKV 的原始碼閱讀文章](https://cn.pingcap.com/blog/?tag=TiKV%20原始碼閱讀)，在這裡就先跳過了。）

### Rafstore -> CDC

- RaftCmd: [CoprocessorHost::on_flush_applied_cmd_batch(Vec<raftcmdrequest>)](https://github.com/tikv/tikv/blob/v6.4.0/components/raftstore/src/store/fsm/apply.rs#L597)
- Txn Record: [Engine::async_snapshot()](https://github.com/tikv/tikv/blob/v6.4.0/src/server/raftkv.rs#L431)
  
從這裡起，資料開始流出了，從 Raftstore 到 CDC 模組有兩條藍線，對應這裡的兩個重要的 API，分別為 `on_flush_applied_cmd_batch` 實時資料的流出，和 `async_snapshot` 歷史增量資料的流出（後面會說細節）。
  
### CDC -> gRPC -> TiCDC
  
- ChangeDataEvent: [Service::event_feed() -> ChangeDataEvent](https://github.com/tikv/tikv/blob/v6.4.0/components/cdc/src/service.rs#LL201C8-L201C18)
  
最後就是從 CDC 模組到 TiCDC 這幾條藍線了。資料進入 CDC 模組後，經過一系列轉換，組裝成 Protobuf message，最後交給 gRPC 透過 ChangeData service 中的 `EventFeed` 這個 RPC 傳送到下游的 TiCDC。
  
### CDC 模組中的資料流動

![UML 圖 (1).jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_1_f57939f8fc.jpg)

上圖示意了資料從 Raftstore 傳送到 TiCDC 模組的細節。
  
資料從 Raftstore 到 CDC 模組，可以分成兩個階段，對應兩條鏈路：
  
- **階段 1，增量掃**，Initializer -> Delegate。
  
  Initializer 從 Raftstore 拿一個 Snapshot，然後在 Snapshot 上讀一些歷史資料變更，讀的範圍有兩個維度：
  
    1. 時間維度 `(checkpoint ts, current ts]`，checkpoint ts 可以理解成 changefeed 上的 checkpoint，current ts 代表 PD leader 上的當前時間。
  
    2. key 範圍 `[start key, end key)`，一般為 region 的 start key 和 end key。
  
- **階段 2，實時寫入監聽**，CdcObserver -> Delegate
  
  `CdcObserver` 實現對實時寫入的監聽。它執行在 Raftstore 的 Apply 執行緒中，只有在 TiCDC 對一個 Region 發起監聽後才會啟動執行。我們知道所有的資料都是透過 Apply 執行緒寫入的，所以說 `CdcObserver` 能輕鬆地在第一時間把資料捕捉到，然後交給 `Delegate` 。
  
我們再看一下資料從 CDC 模組到 gRPC 的流程，大體也有兩部分。第一部分是彙總增量掃和實時寫入；第二部分將這些資料是從 KV 資料反序列化成包含事務資訊的 Protobuf message。我們再將這些事務結構體裡面的資訊給提取出來，填到一個 Protobuf message 裡面。
  
### Raftstore 和 TiCDC 的互動

![UML 圖 (2).jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_2_993f60ef5a.jpg)

上圖是 Raftstore 和 CDC 模組的互動時序圖。第一條線是 TiCDC，第二條是 CDC 執行緒，第三條是 Raftsotre 執行緒，第四條是 Apply 執行緒，圖中每個點都是發生線上程上的一些事件，包含發訊息、收訊息和程式內部的處理邏輯。在這裡我們重點說 Apply 執行緒。
  
Apply 執行緒在處理 Change 這個訊息的時候，它會先要把快取在記憶體中的 KV 的寫入給刷到 RocksDB，然後獲取 RocksDB 的 Snapshot，把 Snapshot 傳送給 CDC 執行緒。這三步是序列的，保證了 Snapshot 可以看到之前所有的寫入。有了這個機制保證，我們就可以確保 CDC 模組既不漏資料，也不多資料。
  
## 資料變更事件有哪些？

![image.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/image_8a167cddf7.png)

資料變更事件可分為兩大類，第一類是 Event；第二類是 ResolvedTs。上圖是 CDC Protobuf 的簡化版定義，只保留了關鍵的 field。我們從上到下看下這個 Protobuf 定義。
  
`EventFeed` 定義了 TiCDC 和 TiKV 之間的訊息互動方式，TiCDC 在一個 RPC 上可以發起對多個 Region 的監聽，TiKV 以 `ChangeDataEvent` 形式將多個 Region 的資料變更事件傳送給 TiCDC。
  
`Event` 代表著是 Region 級別的資料變更事件，包含了至少一個使用者資料變更事件或者或者 Region 後設資料的變更。它們是從單條 Raft Log 翻譯得到的。我們可以注意到 `Event` 被 `repeat` 修飾了，也就是它可能包含了一個 region 多個資料變更，也可能包含多個不同 region 的資料變更。
  
`Entries` 包含了多個 `Row`。因為在 `oneof` 裡面不能出現 `repeated` ，所以我們用 `Entries` 包裝了下。

![image (1).png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/image_1_f3177e681a.png)

`Row` 裡面的內容非常接近 TiDB 層面的資料了，它是行級別的資料變更，包含：
1. 事務的 start ts；
2. 事務的 commit ts；
3. 事務寫入的型別，Prewrite/Commit/Rollback；
4. 事務對資料的操作，`op_type` ，put 覆蓋寫一行和 delete 刪除一行；
5. 事務寫入的 key；
6. 事務寫入的 value；
7. 該事務之前的 value，old value 在很多 CDC 協議上都會有體現，比如說 MySQL 的 maxwell 協議中的 “old” 欄位。
  
## 如何確保完整地捕捉分散式事務的資料變更事件？
  
### 什麼是“完整”？
  
我們需要定義完整是什麼。在這裡，“完整”的主體是 TiDB 中的事務，我們知道 TiDB 的事務會有兩個寫入事件，第一個是 prewrite，第二是 commit 或者 rollback。同時，TiDB 事務可能會涉及多個 key，這些有可能分佈在不同的 region 上。所以，我們說“完整”地捕捉一個事務需要捕捉它涉及的**所有的 key** 和**所有的寫入事件**。

![UML 圖 (3).jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_3_42aee1488c.jpg)

上圖描繪了一個涉及了三個 key 的事務，P 代表事務的 prewrite，C 代表事務的 commit，虛線代表一次捕捉。
  
前面兩條虛線是不“完整”的捕捉，第一條虛線漏了所有 key 的 commit 事件，第二條虛線捕捉到了 k1 和 k2 的 prewrite 和 commit，但漏了 k3 的 commit。如果我們強行認為第二條虛線是“完整”的，則會破壞事務的原子性。
  
最後一條虛線才是“完整”的捕捉，因為它捕捉到了所有 key 的所有寫入。
  
### 如何確認已經“完整”？
  
確認“完整”的方法有很多種，最簡單的辦法就是--等。一般來說，只要我們等的時間足夠長，比如等一輪 GC lifetime，我們也能確認完整。但是這個辦法會導致 TiCDC 的 RPO 不達標。
  
![UML 圖 (4).jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_4_2ed55abe00.jpg)

上圖最後兩條虛線是兩次“完整”的捕捉，假如第四條線十年之後才產生的，顯然它對我們來說是沒有意義的。第四條雖然是“完整”的，但是不是我們想要的。所以我們需要一種機制能夠儘快地告知我們已經捕捉完整了，也就是圖中第三條虛線，在時間上要儘可能地靠近最後一個變更的捕捉。那這個機制的話就是前面提到的 resolved ts。
  
### ResolvedTs 事件及性質

![image (2).png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/image_2_370f9e1f45.png)

ResolvedTs 在 Protobuf 中的定義比較簡單，一個 Region ID 陣列和一個 resolved ts。它記錄了**一批** Region 中**最小的** resolved ts，會混在資料變更事件流中傳送給 TiCDC。從 resolved ts 事件生成的時候開始，TiDB 叢集就不會產生 commit ts 小於 resolved ts 的事務了。從而 TiCDC 收到這個事件之後，便能確認這些 Region 上的資料變更事件的完整性了。
  
### resolved ts 的計算

![image (3).png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/image_3_abee7d0464.png)

Resolved ts 的計算邏輯在 resolver.rs 檔案中，可以用簡單三行虛擬碼表示：
  
- 第一行，它要從 PD 那邊取一個 TS，稱它為 `min_ts`。
- 第二行，我們拿 `min_ts` 和 Region 中的所有 lock 的 start ts 做比較，取最小值，我們稱它為 `new_resolved_ts` 。
- 我們拿 `new_resolved_ts` 和之前的 `resolved_ts` 做比較，取最大值，這就是當前時刻的 resolved ts。因為它小於所有 lock 的 start ts，所有它一定小於這些 lock 的未來的 commit ts。同時，在沒有 lcok 的時候，`min_ts` 會變成 resolved ts，也是就當前時刻 PD 上最新的 ts 將會變成 resolved ts，這確保了它有足夠的實時性。
  
### 資料變更事件流的例子

![UML 圖 (5).jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/UML_5_d5b69856c0.jpg)

上圖是一個資料變更事件流的例子，也就是 gRPC EventFeed 中的 `stream ChangeDataEvent`。
  
例子中有三個事務和三個 resolved ts 事件：
  
- 第一個事務涉及了 k1 和 k2，它的 start ts 是 1， commit ts 是2。
- 第二個事務只包含了 k1 這一個 key，它的 start ts 是 3，commit ts 是 6，注意，這個事務在事件流中出現了亂序，它的 commit 先於 prewrite 出現在這條流中。
- 第三個事務包含了 k2 的一個事務，注意它只有一個 prewrite 事件，commit 事件還沒發生，是一個正在進行中的一個事務。
- 第一個 resolved ts 事件中的 resolved ts 是 2，代表 commit ts 小於等於 2 的事務已經完整傳送，在這個例子中可以把第一個事務安全的還原出來。
- 第二個 resolved ts 事件中的 resolved ts 是 4，這時 k1 的 commit 事件已經傳送了，但是 prewrite 事件沒有，4 就阻止了還原第二個事務。
- 第三個 resolved ts 事件出現後，我們就可以還原第二個事務了。
  
## 結尾
  
以上就是本文的全部內容。希望在閱讀上面的內容後，讀者能知道文章開頭的四個問題和了解：
  
- ?資料從 TiDB 寫入到 TiKV CDC 模組輸出的流程
- ?️瞭解如何完整地捕捉分散式事務的資料變更事件</raftcmdrequest>

TiCDC 原始碼閱讀（二）TiKV CDC 模組介紹

相關文章