共计 3617 个字符，预计需要花费 10 分钟才能阅读完成。
内容概要
TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 能够将数据解析为有序的行级变更数据输入到上游。
本文是 TiCDC 源码解读的第三篇，次要内容是讲述 TiCDC 集群的启动及根本工作过程，将从如下几个方面开展：
- TiCDC Server 启动过程，以及 Server / Capture / Owner / Processor Manager 概念和关系
- TiCDC Changefeed 创立过程
- Etcd 在 TiCDC 集群中的作用
- Owner 和 Processor Manager 概念介绍，以及 Owner 选举和切换过程
- Etcd Worker 在 TiCDC 中的作用
残缺视频回顾
启动 TiCDC Server
启动一个 TiCDC Server 时，应用的命令如下，须要传入以后上游 TiDB 集群的 PD 地址。
cdc server --pd=http://127.0.0.1:2379它会启动一个 TiCDC Server 运行实例，并且向 PD 的 ETCD Server 写入 TiCDC 相干的元数据，具体的 Key 如下：
/tidb/cdc/default/__cdc_meta__/capture/${capture_id}
/tidb/cdc/default/__cdc_meta__/owner/${session_id}
第一个 Key 是 Capture Key，用于注册一个 TiCDC Server 上运行的 Capture 信息，每次启动一个 Capture 时都会写入相应的 Key 和 Value。
第二个 Key 是 Campaign Key，每个 Capture 都会注册这样一个 Key 用于竞选 Owner。第一个写入 Owner Key 的 Capture 将成为 Owner 节点。
Server 启动，通过了解析 Server 启动参数，验证参数合法性，而后创立并且运行 TiCDC Server。Server 运行的过程中，会启动多个运行线程。首先启动一个 Http Server 线程，对外提供 Http OpenAPI 拜访能力。其次，会创立一系列运行在 Server 级别的资源，次要作用是辅助 Capture 线程运行。最重要的是创立并且运行 Capture 线程，它是 TiCDC Server 运行的次要性能提供者。
Capture 运行时，首先会将本人的 Capture Information 投入到 ETCD 中。而后启动两个线程，一个运行 ProcessorManager，负责所有 Processor 的管理工作。另外一个运行 campaignOwner，其外部会负责竞选 Owner，以及运行 Owner 职责。如下所示，TiCDC Server 启动之后，会创立一个 Capture 线程，而 Capture 在运行过程中又会创立 ProcessorManager 和 Owner 两个线程，各自负责不同的工作工作。
创立 TiCDC Changefeed
创立 changefeed 时应用的命令如下：
cdc changefeed create --server=http://127.0.0.1:8300 --sink-uri="blackhole://" --changefeed-id="blackhole-test"其中的 server 参数标识了一个运行中的 TiCDC 节点，它记录了启动时候的 PD 地址。在创立 changefeed 时，server 会拜访该 PD 内的 ETCD Server，写入一个 Changefeed 的元数据信息。
/tidb/cdc/default/default/changefeed/info/${changefeed_id}
/tidb/cdc/default/default/changefeed/status/${changefeed_id}- 第一个 Key 标识了一个 Changefeed，包含该 Changefeed 的各种动态元数据信息，比方
changefeed-id，sink-uri，以及一些其余标识运行时是为的数据。 - 第二个 Key 标识了该 Changefeed 的运行时进度，次要是记录了
Checkpoint和ResolvedTs的推动状况，会一直地周期性地更新。
Etcd 的作用
ETCD 在整个 TiCDC 集群中承当了十分重要的元数据存储性能，它记录了 Capture 和 Changefeed 等重要信息。同时通过一直记录并且更新 Changefeed 的 Checkpoint 和 ResolvedTs，保障 Changefeed 可能稳步向前推动工作。从上图中咱们能够晓得，Capture 在启动的时候，自行将本人的元数据信息写入到 ETCD 中，在此之后，Changefeed 的创立，暂停，删除等操作，都是经由曾经启动的 TiCDC Owner 来执行的，后者负责更新 ETCD。
Owner 选举和切换
一个 TiCDC 集群中能够存在着多个 TiCDC 节点，每个节点上都运行着一个 campaignOwner 线程，负责竞选 Owner，如果竞选胜利，则履行 Owner 的工作职责。集群中只有一个节点会竞选胜利，而后执行 Owner 的工作逻辑，其余节点上的该线程会阻塞在竞选 Owner 上。
TiCDC Owner 的选举过程是基于 ETCD Election 实现的。每个 Capture 在启动之后，会创立 ETCD Session，而后应用该 Session，调用 NewElection 办法，创立到 Owner Key /tidb/cdc/${ClusterID}/__cdc_meta/owner 的竞选，而后调用 Election.Campaign 开始竞选。根本的相干代码过程如下：
sess, err := concurrency.NewSession(etcdClient, ttl) // ttl is set to 10s
if err != nil {return err}
election := concurrency.NewElection(sess, key) // key is `/tidb/cdc/${ClusterID}/__cdc_meta/owner`
if err := election.Campaign(ctx); err != nil {return err}
...
感兴趣的读者，能够通过 Capture.Run 办法作为入口，浏览这部分代码流程，加深对该过程的了解。在实在的集群运行过程中，多个 TiCDC 节点先后上线，在不同的时刻开始竞选 Owner，第一个向 ETCD 中写入 Owner Key 的实例将成为 Owner。如下图所示，TiCDC-0 在 t=1 时刻写入 Owner Key，将会成为 Owner，它在后续运行过程中如果遇到故障辞去了本人的 Ownership，那么 TiCDC-1 将会成为新的 Owner 节点。老旧的 Owner 节点从新上线，调用 Election.Campaign 办法从新竞选 Owner，周而复始。
EtcdWorker 模块
EtcdWorker 是 TiCDC 外部一个十分重要的模块，它次要负责从 ETCD 中读取数据，映射到 TiCDC 内存中，而后驱动 Owner 和 ProcessorManager 运行。在具体的实现中，EtcdWorker 通过调用 ETCD Watch 接口，周期性地获取到所有和 TiCDC 相干的 Key 的变动状况，而后映射到其本身保护的 GlobalReactorState 构造体中，其定义如下所示，其中记录了 Capture，Changefeed，Owner 等信息。
type GlobalReactorState struct {
ClusterID string
Owner map[string]struct{}
Captures map[model.CaptureID]*model.CaptureInfo
Upstreams map[model.UpstreamID]*model.UpstreamInfo
Changefeeds map[model.ChangeFeedID]*ChangefeedReactorState
....
}Owner 和 ProcessorManager 都是一个 Reactor 接口的实现，二者都借助 GlobalReactorState 提供的信息来推动工作进度。具体地，Owner 通过轮询每一个记录在 GlobalReactorState 中的 Changefeed，让每一个 Changefeed 都可能被稳步推动同步状态。同时也负责诸如 Pause / Resume / Remove 等和 Changefeed 的运行状态相干的工作。ProcessorManager 则轮询每一个 Processor，让它们可能及时更新本身的运行状态。
总结
以上就是本文的全部内容。心愿读者可能了解如下几个问题：
- TiCDC Server 启动，创立 Changefeed 和 ETCD 的交互过程。
- EtcdWorker 如何读取 ETCD 数据并且驱动 Owner 和 Processor Manager 运行。
- TiCDC Owner 的竞选和切换过程。
下一次咱们将向大家介绍 TiCDC Changefeed 外部的 Scheduler 模块的工作原理。
