tidb cdc 原理

https://www.modb.pro/doc/124130 ptcp v6 题库
https://www.modb.pro/doc/123201 ptca v6 题库

obca 认证题库 https://www.modb.pro/doc/129748

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 可以完整地处理这批事务了。

3. 上图示意了数据从 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

4.