此处理器负责引导新表。它查找 CDC 配置以确定快照模式，并在需要时对启用了 CDC 的表执行快照。要对表进行快照，代理将执行完整的表扫描，并将结果集中的每一行转换为单个创建事件，然后按顺序将它们排入内存中的 BlockingQueue。

此处理器负责监视 CDC 目录中的新提交日志，通过 Cassandra 的 CommitLogReader 解析提交日志文件，将反序列化的变异转换为标准化的更改事件，最后将它们排入与快照处理器相同的队列。

此时，一些读者可能对并发运行快照处理器和提交日志处理器而不是串行运行感到担忧。原因是 Cassandra 使用 客户端时间戳 来确定事件顺序，并以最后写入获胜的方式解决冲突。这个客户端时间戳被刻意存储在每个更改事件中。这就是为什么快照不必在提交日志处理之前执行——顺序稍后在数据仓库中查询数据时确定。

此处理器负责从队列中取出更改事件，将它们转换为 Avro 记录，并通过 Kafka 生产者将它们发送到 Kafka。它还跟踪最近发送的事件的位置，以便在重新启动时能够从上次中断的地方继续。

乍一看，在 CDC 代理中实现内存队列似乎有些夸张。鉴于只有一个线程执行入队操作，另一个线程执行出队操作，性能提升微乎其微。动机在于解耦解析提交日志的工作（应按正确顺序串行执行）与序列化和发布 Kafka 事件的工作（可以由多个线程为不同表并行执行）。尽管目前尚未实现这种并行化，但我们希望将来能够灵活地添加此功能。

有些人可能还会想知道为什么不使用 Kafka Connect，因为它似乎是流式传输的自然选择。如果我们想要具有容错能力的分布式并行处理，这是一个很好的选择。然而，与 Kafka 生产者相比，它的部署、监控和调试更加复杂。为了构建最小可行基础设施，我们当时选择了 Kafka 生产者。

为了支持自动架构演进，此处理器会定期轮询数据库以获取最新的表架构，并在检测到更改时更新内存中的架构缓存。快照处理器和提交日志处理器都从此缓存中查找表架构，并将其作为更改事件的一部分附加到入队之前。然后在出队时，队列处理器会将附加的表架构转换为 Avro 架构以进行记录序列化。

此处理器负责在提交日志被处理后进行清理。默认的提交日志后处理器实现将只执行删除操作。可以为特定用例配置自定义提交日志后处理器，例如将提交日志文件归档到 S3 或 GCS。

BigQuery 视图是虚拟的事实意味着每次查询视图时实际上都会触发原始数据的完整压缩。这意味着成本会随着查询次数的增加而增加，更不用说重复的事件将需要处理的数据量放大了 N 倍（其中 N 是复制因子）。为了节省成本并提高性能，有必要通过具体化视图来定期进行压缩。

在 Cassandra 4.0 中，改进的 CDC 功能允许连接器实时解析写入的事件，而不是在每次提交日志刷新时进行微批量处理。这大大降低了延迟。

如前所述，有一个线程负责出队、序列化和发布 Kafka 记录。然而，随着写入吞吐量的增加，如果代理的性能跟不上，就会导致未处理的提交日志堆积，这可能会影响我们生产数据库的健康状况。下一步是利用事件的并行处理来优化性能。

我们最初将 Cassandra CDC 代理构建为一个独立项目。现在它已作为 Debezium 连接器开源，我们可以用 Debezium 中的现有类替换我们的一些自定义类。另一个改进是支持所有 Debezium 连接器的通用功能，例如支持多种序列化格式。最后，CDC 代理不是容错的；部署时需要健壮的警报和监控。未来要探索的一个领域是基于 Kafka Connect 构建 CDC 代理作为源连接器，这进一步简化了 Cassandra 连接器与其他 Debezium 连接器的集成，并免费提供了可伸缩性和容错能力。

通过剥离除基本功能之外的所有功能，我们在有限的资源下，能够在合理的时间内构建、测试和部署一个可行的解决方案。如果我们一开始就打算设计一个包含所有功能的管道，这将花费更长的时间并需要更多的资源。

Cassandra 是一个开源项目。与其独自解决问题，不如从一开始我们就与 Cassandra 社区进行互动（例如，通过 聚会 与提交者和用户分享经验，在 邮件列表讨论提案，在 会议上展示概念验证 等）；所有这些都在设计和实施阶段为我们提供了宝贵的反馈。