数据同步平台技术选型报告
1. 文档目的
本文依据 需求基线 对 V1 技术路线进行选型。船端现有 Kafka 承载关键业务，不作为平台 CDC 积压的默认承载设施；评价重点是独立部署成本、弱网可靠性及对既有业务的隔离效果。
需求基线中的 FR/NFR/AC 是评价依据；当本文与需求基线冲突时，以需求基线为准。
1.1 选型术语
- “候选”表示仍在比较的技术；“选定”表示 V1 的技术方向已冻结，但仍须完成本文所列 PoC；“不采用”表示不作为 V1 方案，不代表该技术永远不可使用。
- “技术基线”表示实现必须围绕该组合进行兼容性和容量验证；“生产参数”表示 PoC 后固化的版本、资源、保留和部署参数，二者不等同。
- “独立队列”表示平台拥有独立的 Topic/命名空间、数据目录、资源配额、保留策略和故障处置边界；是否与业务系统共用物理服务器，必须另行验证。
- 本报告中的 Kafka、Kafka API、Kafka Connect、Debezium、Redpanda、Topic、partition、consumer offset 和 source offset 均是选型实现术语，业务含义分别回到需求基线中的 CDC 采集、CDC 事件队列、队列分区位点和源数据库位点。
- “无状态多副本”仅指岸端 Go 服务实例不保存不能丢失的本地权威工作流状态；PostgreSQL、岸端业务 MySQL 和已选 CDC 事件队列仍是有状态依赖。
GTID指 MySQL 全局事务标识，用于 CDC 位点恢复和诊断；SMT指 Kafka Connect Single Message Transform，只能作为已选 CDC 组件边界内的受控消息变换；HPA指 Kubernetes Horizontal Pod Autoscaler；PDB指 Pod Disruption Budget；NAT指网络地址转换；RTT指往返时延；WAL指 SQLite Write-Ahead Logging。它们是技术选型术语，不改变需求中的业务语义。Topic是事件队列中按名称管理的逻辑事件流；partition是 Topic 内保持顺序的子流；offset是消息在 partition 内的位置；Inbox是岸端 PostgreSQL 中保存已接收上行事件及其处理状态的逻辑区域，不是 CDC 事件队列；Downlink Queue是保存可靠下行命令的 PostgreSQL 逻辑区域，不是岸端 CDC Topic。Connect Worker是运行 Kafka Connect 连接器任务的进程或进程组；source lag是 CDC 采集组件已读取的源数据库日志位置与源端最新位置之间的差距；schema history是 CDC 组件为解释后续日志事件而持久化的源表结构历史。二者属于采集组件运维指标和内部数据，不是平台业务事件。标准化是把具体 CDC 产品的原始事件转换为平台定义的变更事件；可靠存储是写入重启后仍可恢复读取的持久化介质并完成提交确认；独立部署是组件在逻辑资源、数据目录、保留策略和故障处置上与业务消息基础设施隔离，不等于物理机独占。
2. 选型结论
V1 选定“Kafka Connect + Debezium 成熟 CDC + 独立 Redpanda 事件队列 + Go 弱网同步与岸端服务”。Redpanda 提供 Kafka API 兼容接口和独立队列实例，避免平台与既有业务 Kafka 共享 Topic、保留策略和数据目录；是否形成独立物理故障域取决于最终主机与磁盘部署。PoC 用于固化兼容版本、容量、资源隔离和运行参数，不用于重新开启无约束选型。
| 层次 | 推荐技术 | 结论 |
|---|---|---|
| 船端 CDC | Kafka Connect + Debezium MySQL Source Connector | V1 技术基线；Connect 写入独立 Redpanda。 |
| 船端 CDC 事件队列 | Redpanda | V1 选定；通过 Kafka API 承载 CDC Topic 和数月离线积压，与业务 Kafka 隔离。 |
| 船端同步客户端 | Go | 消费 CDC 事件队列、标准化、规则、限速传输、事件处理结果拉取和下行命令应用。 |
| 船端本地状态 | SQLite WAL | 保存规则、事件处理索引、平台检查点、下行命令及其处理结果和审计摘要，不重复存储完整 CDC 积压。 |
| 船岸协议 | HTTPS 批量 API + Protobuf + zstd | 适合断线恢复；Kafka 不跨船岸直接复制。 |
| 岸端服务 | Go | Kubernetes 无状态多副本，面向至少 1,000 个船端并发。 |
| 岸端平台状态 | PostgreSQL | 节点、规则、Inbox、事件处理结果、冲突、审计和持久任务。 |
| 岸端 CDC 事件队列 | Redpanda | 承载岸端 MySQL 的 Debezium 事件；与 PostgreSQL Inbox/下行任务职责分离。 |
| 管理后台 | React + TypeScript | 采用。 |
| 部署 | OCI + Compose + Kubernetes | 船端离线 Compose，岸端 Kubernetes。 |
自研边界限定为业务差异化能力：Debezium 事件标准化、弱网传输、接收确认、终态事件处理结果、下行命令处理结果、数据集窗口、积压与 ETA、双向防环、目标应用和冲突裁决。不自研 MySQL binlog 协议、Debezium 初始快照或消息代理。
3. 基础设施前提
3.1 业务 Kafka 与 CDC 队列隔离
船端现有 Kafka 是关键业务支点。平台默认新增独立 Redpanda 实例，不在业务 Kafka 创建 CDC Topic，也不共享数据目录、磁盘水位或保留策略。Redpanda 可与业务 Kafka 共用服务器的前提是 CPU、内存、磁盘 I/O、端口、监控和故障处置均有明确隔离，并通过并行负载 PoC。
CDC 事件队列的可用容量按下式估算：
required_disk = daily_cdc_bytes * retention_days * replication_factor
* serialization_overhead * safety_factor
安全系数建议不低于 1.3，最终由 POC-013 固化。CDC Topic 不得依赖固定时长或固定字节上限自动删除业务未处置的数据；前缀清理只能推进到各分区连续平台检查点，并保留审计要求的安全窗口。若存储上限无法满足，必须扩容或按审批后的数据集窗口处置，不能将风险转移到业务 Kafka。
3.2 双向冲突检测
Debezium 只能描述已提交变更，不能得知业务写入时观察到的远端版本。双向表仍必须提供 sync_revision 或等价基线元数据；否则只能单向同步或采用业务明确接受的覆盖策略。
3.3 队列消费位点、接收确认与平台检查点
- Kafka API consumer offset 表示 Go 客户端在 Redpanda 分区中提交的下一读取位置。
- 接收确认表示事件已可靠进入接收方的可恢复存储。
- 平台检查点表示一个处理契约的来源分区中已连续获得该契约终态结果的位置；岸端本地 CDC 事件在可靠下行命令持久化后得到
FORWARDED，船端命令另以COMMAND_APPLIED等命令结果确认。
船端 Go 客户端不得在仅发送成功或岸端仅接收后提交越过平台检查点的 consumer offset。完整上行事件在船端 Redpanda 中保存，SQLite 保存 topic + partition + offset 与事件处理结果的索引。岸端 CDC 事件进入 PostgreSQL 可靠下行命令后，可推进岸端 Redpanda 的平台检查点；下行命令在船端获得命令处理终态前继续由 PostgreSQL 保存。提交 consumer offset 本身不会删除 Topic 数据，队列保留与平台清理必须分别治理。
3.4 双向防环
任一端应用远端变更后，该写入都会再次被本端 Debezium 捕获。目标应用必须写入来源事件和版本标记；对应 CDC 消费者识别该标记，只推进平台状态，不再次生成反向事件或命令。
4. 评价准则
方案必须同时满足以下准则，不使用缺乏实测数据的伪精确加权分数：
- 正确捕获 MySQL 事务、快照、删除、GTID/位点并支持故障恢复。
- 承载数月、数十至上百 GiB 的船端积压，且不影响既有业务 Kafka。
- 支持标准事件、防环、上行事件处理结果、下行命令处理结果、窗口、ETA 和岸端统一裁决。
- 新增组件可离线交付、独立观测、升级和回退，资源成本可在目标硬件验证。
- 岸端可支撑 1,000 个船端集中重连并在 Kubernetes 水平扩展。
5. CDC 方案比较
| 候选 | 决策 | 主要依据 |
|---|---|---|
| Kafka Connect + Debezium | 选定 | 成熟的 MySQL 快照、binlog、schema history 和 source offset 能力，可通过 Kafka API 写入 Redpanda。 |
| Debezium Server | 不采用 | 与选定方案复用同一 CDC 引擎，但引入另一套运行和运维方式。 |
go-mysql / Canal | 条件备选 | 只有选定组合命中否决条件且无法治理时，才通过新 ADR 评估。 |
| 从零实现 binlog | 不采用 | 重复实现通用 CDC，恢复正确性和维护成本不可接受。 |
Debezium MySQL Source Connector 负责快照、binlog、schema history 和 source offset；Kafka Connect 负责连接器生命周期与 source offset 管理。它们不负责船岸弱网传输、终态事件处理结果、目标应用和冲突裁决。
6. CDC 事件队列比较
| 候选 | 决策 | 隔离与成本 |
|---|---|---|
| 独立 Redpanda | 选定 | Kafka API 兼容；独立 Topic、保留策略和数据目录；新增镜像与资源须单独验收。 |
| 独立 Apache Kafka | 不优先 | 隔离能力满足，但在本项目中新增部署和运行依赖更重；仅作为 Redpanda 不兼容时的成熟回退。 |
| 既有业务 Kafka | 默认不采用 | 交付增量最小，但 CDC 长期积压、磁盘水位和恢复回放可能影响关键业务。只有专项影响评估通过后才可复用。 |
| SQLite/文件自研队列 | 不采用 | 会形成第二份大规模事件存储，并自研分区、保留、回放和损坏恢复能力。 |
V1 直接验证 Kafka Connect + Debezium + Redpanda。只有该组合命中第 11.2 节否决条件，且无法通过版本调整、配置治理或独立资源扩容解决时，才允许通过新 ADR 评估替代方案。不得仅因团队语言偏好切换到自研 CDC，也不得为节省一个实例而默认复用业务 Kafka。
6.1 选定组合
船端：MySQL -> Kafka Connect/Debezium -> Redpanda CDC Topic -> Go 同步客户端。Redpanda 保存完整上行 CDC 积压；SQLite 只保存平台状态索引和从岸端拉取的下行命令，不形成第二份完整上行队列。
岸端：岸端 MySQL 的本地业务写入由 Kafka Connect/Debezium 捕获并进入岸端 Redpanda，再由岸端 CDC Consumer 转换为面向目标船端的可靠下行命令。船端上行事件由岸端接收模块保存，PostgreSQL 承载上行 Inbox、事件处理结果、冲突和可靠下行命令，岸端 MySQL 保存业务数据。岸端 Redpanda 只承担 CDC 事件队列，不替代 PostgreSQL 工作流状态。
6.2 不使用 Broker 跨站复制代替船岸协议
消息代理跨站复制不能直接满足按规则过滤、数据集窗口、接收确认与终态处理结果、目标 MySQL 幂等应用、岸端唯一裁决和人工处理。船岸链路使用平台 HTTPS 批量协议，不直接暴露 Redpanda 或业务 Kafka。
6.3 Go 的定位
Go 不再承担 MySQL binlog 解析。它用于新增同步客户端和岸端服务，以控制增量镜像、实现弱网调度，并支撑大量并发连接。选择 Go 仍需通过千节点和资源压测验证。
7. Redpanda、Kafka Connect 与 Debezium 选择
7.1 Topic 规划
| Topic | 用途 | 建议键 |
|---|---|---|
sync.cdc.<database>.<table> | Debezium 原始 CDC | 业务主键。 |
| 平台失败摘要存储 | 不可解析或永久规则错误的元数据与原因；不保存未脱敏完整载荷 | 由 SQLite/PostgreSQL 逻辑表承载，不另设 sync.dlq Topic。 |
| Kafka Connect 内部 Topic | config、offset、status | 存储于独立 Redpanda，按 Connect 规范。 |
是否按表或规则进一步合并 Topic 由表数量和分区规模 PoC 决定。Topic 命名不得把船端密钥或敏感业务值放入名称。
7.2 保留策略
- CDC Topic 使用
delete策略，不使用 compaction 替代完整变更历史。 - CDC 正文默认关闭按时间和按字节自动淘汰；平台按连续检查点执行受控前缀清理。若产品版本无法满足该配置与清理语义，则 POC-013 不通过。
- 容量规划覆盖承诺的最大离线期和清理安全窗口；容量不足时使用需求基线中的扩容或审批处置，不得静默缩短保留期。
- 磁盘预警必须早于 Redpanda 最低可用水位；平台积压页面显示最早/最新 offset 和预计字节。
- Topic 数据删除是不可逆动作，不能仅依据 consumer offset 判断业务已成功应用。
7.3 Schema 与序列化
Debezium 输出保留 schema 信息。Go 客户端通过版本化适配器转换为平台 Protobuf 标准事件；平台协议不暴露 Debezium Envelope。V1 优先使用 Connect JSON Converter 的 schema 模式以降低额外组件依赖；若消息体积不达标，再评估 Avro/Protobuf Converter 与 Schema Registry。
7.4 Connect 部署
- Kafka Connect 独立部署或复用已认证且与业务负载隔离的 Connect Worker。
- 连接器配置版本化保存，禁止仅在控制台手工修改。
- Connect 内部 Topic 必须写入独立 Redpanda 并设置与部署拓扑一致的复制因子。
- Debezium、Kafka Connect、Redpanda 及所用 Kafka API 的兼容矩阵通过 PoC 固化。
- Connector、任务、快照、source lag 和错误状态接入平台观测。
8. 其他组件选择
8.1 Go 同步客户端状态库
SQLite WAL 保存规则、消费分区状态、事件到平台事件处理结果的索引、下行命令、审计摘要和统计采样。完整 CDC value 默认留在 Redpanda，避免 100 GiB 双份存储。
若事件处理索引或下行命令规模使 SQLite 不达标，须通过新 ADR 选择替代状态库；本报告不预先指定 Pebble。禁止在本地状态持久化失败后推进平台检查点或提交对应 consumer offset。
8.2 船岸协议
采用 HTTPS 批量 API + Protobuf + zstd。客户端发起请求，适合 NAT、高延迟和频繁断线环境。Go 客户端主动上传并拉取事件处理结果与下行命令；是否使用 HTTP 长连接属于实现参数，不改变请求模型。
8.3 岸端架构与 Kubernetes
岸端采用 Go 模块化单体和 PostgreSQL。相同镜像按接收、事件处理、岸端 CDC 消费和管理职责运行，可按容量合并或拆分启动模式；使用 Helm、HPA、PDB、健康检查和优雅终止。生产环境的业务 MySQL 与 PostgreSQL 默认使用平台外高可用实例。
9. 逻辑架构
10. 需求追踪
| 需求 | 技术响应 |
|---|---|
| FR-001、FR-010、FR-011 | Go 管理 API、React 控制台、PostgreSQL 节点与规则状态。 |
| FR-002、FR-004、FR-005 | Debezium MySQL Connector 的行级变更、快照与增量 CDC。 |
| FR-003、FR-007 | 版本化标准规则模型与 Go Rule Runtime。 |
| FR-006、FR-014 | Redpanda 持久事件、Go 批量重试、接收确认、终态事件处理结果和幂等处理。 |
| FR-008、FR-009 | 来源元数据、版本基线和岸端唯一裁决。 |
| FR-012、FR-013 | Go 调度器、Redpanda/SQLite 统计、窗口和 ETA。 |
| FR-015、NFR-113 至 NFR-115 | Go 镜像体积目标；Redpanda、Connect、Debezium 单独计量并验证业务隔离。 |
| FR-016 | Kafka Connect + Debezium + 独立 Redpanda CDC Topic。 |
| NFR-101、NFR-116、NFR-117 | Go 无状态服务、Kubernetes 多副本、HPA 和故障演练。 |
11. PoC 与否决条件
11.1 必测场景
- 盘点业务 Kafka 服务目标和船端资源，验证 Redpanda、Kafka Connect 与 Debezium 兼容矩阵及隔离方案。
- Debezium 快照期间持续写入，验证快照与增量无缺口。
- Redpanda 累积 10 GiB、100 GiB，验证磁盘水位、保留、重启和回放，同时观察业务 Kafka 基线指标。
- Go 客户端在读取、上传、接收确认、终态事件处理结果前后崩溃，验证 offset 与业务结果可对账。
- 128 KiB/s、600 ms RTT、5% 丢包和频繁断线下验证调度。
- Go 增量镜像和离线包的体积、资源、升级与回退。
- 1,000 船端集中重连及 Kubernetes 滚动升级、驱逐和扩缩容。
- 双向冲突、窗口缩减和 100 GiB 积压 ETA。
11.2 否决条件
- 船端无法为 Redpanda 提供与业务 Kafka 隔离的容量和故障边界，且业务不接受窗口化处置或离线介质方案。
- Redpanda、Kafka Connect 与 Debezium 的版本组合无法稳定支持目标 MySQL、类型、快照、GTID/位点恢复或所需 Kafka API。
- Go 客户端无法可靠关联 Topic/Partition/Offset 与平台终态事件处理结果。
- 新增镜像、资源或升级流程不满足 NFR-113 至 NFR-115。
- 1,000 节点集中重连无法通过水平扩展恢复到容量基线。
- 故障恢复出现无法对账的数据丢失或重复业务效果。
12. ADR 清单
| ADR | 决策 | 状态 |
|---|---|---|
| ADR-001 | Kafka Connect + Debezium 作为 V1 CDC 技术基线。 | 已接受；具体版本待 POC-013 固化。 |
| ADR-002 | Go 负责弱网同步客户端和岸端服务，不自研 binlog 协议。 | 已接受；资源参数待 PoC 固化。 |
| ADR-003 | 独立 Redpanda 是船端 CDC 主队列，SQLite 只保存平台状态和下行数据；业务 Kafka 默认不承载平台 Topic。 | 已接受；保留、容量和隔离参数待 PoC 固化。 |
| ADR-004 | V1 采用 HTTPS 批量协议、Protobuf 和 zstd。 | 待协议 PoC。 |
| ADR-005 | 岸端采用 Go 模块化单体和 Kubernetes 多副本。 | 已接受；副本与容量参数待 PoC 固化。 |
| ADR-006 | 双向表必须提供版本基线，岸端拥有唯一裁决权。 | 已接受。 |
| ADR-007 | 岸端使用 Redpanda 承载岸端 MySQL CDC；PostgreSQL 继续承载 Inbox、事件处理结果和下行工作流。 | 已接受；容量参数待 PoC 固化。 |
“已接受”表示技术方向已冻结，不表示可以跳过验证。若 PoC 命中否决条件，应记录证据并新增替代 ADR，不直接改写本报告中的既有决策历史。