调研 + 方案 · 2026-11-05

数据库同步工具盘点，以及一个 Go 内核的新工具该怎么切进去

DataX / dbswitch / DBSyncer / Canal / Debezium / PeerDB / pgstream / Benthos 全线体检 → 空白点 → 架构 → MVP

一句话结论

市场不缺「批量搬数据」，也不缺「CDC 吐 Kafka」，缺的是一次配置、迁移与增量同一套语义、无 JVM 无 Kafka 依赖、且能吃国产库的单二进制工具。

2.5 vs 21 分钟1000 万行：Go CDC 库 vs Debezium
130 MB vs 1.07 GB同一次同步的峰值内存
10 GB / 任务DataX 大表任务的内存占用
0 个开源中「迁移+CDC 一体」的成熟品
建议：Go 做内核（协议成熟度决定成败），Rust 只留给后续纯 CPU 热路径。定位选「异构 + 国产库 + 无 Kafka 依赖 + 迁移即 CDC」这条缝，不跟 SeaTunnel 比连接器数量。

你点名的四个，先各自定性

工具本质强项死角
DataX
阿里·Java		离线批量，单机多线程
Reader→Channel→Writer		稳、插件多、流控精准、无外部依赖只做 T+1；大表 1 任务吃 10G 内存；无自动集群（实测 15 台机手配）；无 Web
dbswitch
dromara·Java		结构迁移 + 批量同步
JDBC 分批 + copy		方言覆盖最广：达梦/金仓/highgo/oscar/gbase/openGauss/uxdb 全有靠 JDBC 拉，压源库；没有日志 CDC；变化量同步「千万级性能未验证」
DBSyncer
86dbs·Java		Web 控制台式同步中间件24 种连接器（Kafka/RocketMQ/Redis/Mongo/ES/DuckDB…）+ 可视化 + 插件JVM、Web 重、按月级运维；DDL 不同步
DBSync
商业·Windows		「扫描比对找差异」定时同步绿色免安装、双向、免费版能用不读日志，靠全表扫比对 → 大数据量不可行；闭源
dbdatasync没找到有影响力的同名项目（多为个人脚本/私有交付物）。按「离线批量+定时」归到上面第一类即可，不构成竞品。
一句话：这四个全是「定时搬存量」的思路，只有 DBSyncer 碰了增量，而且没有一个是日志级 CDC。你要的低延迟，它们这一层给不了。

开源 CDC 梯队：谁真正在跑

项目语言形态关键事实
Canal
阿里		Java伪装 slave 读 binlog只 MySQL；没有全量快照；出 Kafka/RocketMQ
Debezium
Red Hat		JavaKafka Connect 源连接器最全、事实标准；必须拖 Kafka；基准里吃 8–10 GB、默认 15k ops/s
Flink CDCJavaFlink connector无锁并行快照 + checkpoint；要一整套 Flink
SeaTunnel
Apache 顶级		JavaZeta/Flink/Spark 引擎批流一体、100+ 连接器、自带无锁快照 + schema evolution + 动态加表；重
PeerDB
已被 ClickHouse 收购		Go单二进制，PG→CH无 Kafka 依赖、slot 增长监控、resync、schema 演进；只强在 PG→ClickHouse
pgstream
Xata		GoCLI + 库唯一把 DDL 变更当一等公民；出 PG/Kafka/OpenSearch/Webhook
go-pq-cdc
Trendyol		Go库 + 连接器生产验证；1000 万行 2.5 分钟、130 MB —— Go 能打赢 JVM 的硬证据
Benthos / Redpanda ConnectGo单二进制 30 MB300+ 连接器、YAML 即管道、冷启 <1s；但数据库源是拉取式，不读日志
Supermetal
新，非 JVM		—CDC 服务快照 2× 吞吐 / 一半 CPU；live 默认配置 35k ops/s，slot lag <100 MB
Rust 侧Rust库/碎片pgwire-replication、rustcdc、EasyPost binlog（只有 parser，没有网络复制流）、mysql-binlog-connector-rust；Supabase ETL 仍是 git-only

商业那一头，已经把答案写好了

CloudCanal / TapData / BladePipe / DataPipeline 卖的就是「端到端、无 Kafka、含国产库」这件事——说明需求成立，但开源这一层是空的。

厂商卖点参考价格/门槛
CloudCanal60+ 数据源、<3s 延迟、达梦走 DBMS_LOGMNR、表级位点并行自托管约 ¥483/月起（BYOC）
TapData100+ 连接器、国产库裸日志解析、拖拉拽企业版闭源，社区版功能受限
BladePipe / DataPipelineKafka-less CDC、批流一体商业授权
Fivetran / Airbyte / Estuary全托管，SaaS 长尾源$3600/月起量级

机会他们闭源他们贵且绑定

四个真空白（也是你的产品定义）

  1. 迁移与增量是两拨工具。dbswitch 管结构+全量，Debezium 管增量，中间「无缝切换、不丢不重」要人肉拼。商业产品才把这一步做进一个进程。
  2. 国产库 CDC 开源几乎为零。达梦 DM8 LogMiner、金仓、openGauss、崖山，只有闭源商业支持；开源能碰的只有 JDBC 批量。这块你有真实客户场景（abjt 就是金仓）。
  3. JVM 税 + Kafka 门票。重度用户被迫为「读个日志」付 8–10 GB 内存和一整套 Kafka。
  4. 单机不可横扩。DataX 单机、Debezium 单并发 WAL——表一多就排队。

Go 还是 Rust：别从语言出发

这条产品的壁垒是协议覆盖 + 事务语义正确 + 运维体验，不是运行时。而恰恰在「异构协议」这条最难的路上，Rust 的弹药最少。

维度GoRust
PG 逻辑复制jackc/pglogrepl，十年生产验证pgwire-replication（单人维护）/ pg-walstream
MySQL binloggo-mysql（canal）：解析 + 网络复制流全有只有 parser；网络复制流要自己写
Oracle / 达梦 / 金仓纯协议实现或 C 库 cgo，路清楚无 crate，只能 FFI 或重写
并发模型goroutine：一表/一分片一协程，天然tokio 更精细，但状态机复杂度高
内存 / p99130 MB 级（实测），GC 可调<20 MB，无抖动
交付单静态二进制、交叉编译极简单二进制、但 TLS/DB 依赖交叉编译麻烦
开发速度基准约 2–3×
结论：Go 主干；Rust 只在「解析/编码」这类纯 CPU 热点做可选 FFI 模块（先不做）。
唯一该整条选 Rust 的场景：跑在边缘设备（<20 MB）或要求单核 10 万+ ops/s。

架构：六段管道 + 一个关键设计

① Source 连接器PG 逻辑复制 / MySQL binlog / Oracle LogMiner / 国产库；快照与增量同一个接口
② 事务组装按 commit 边界成批；大事务流式切分；回滚直接丢弃
③ Transform表/列映射、类型转换、过滤、脱敏、宽表拼接（配置即 DSL，不做流计算）
④ 批聚合 + 背压group commit（先到 500 行或 1ms 触发）；有界队列满则暂停读取
⑤ Sink目标库 upsert / Kafka / NATS / Redis Streams / ClickHouse / ES
⑥ 位点和数据同一个目标库事务写进 _ds_meta
关键设计：位点不存本地文件、不进外部协调器，而是「随数据一起提交进目标库」。
→ 崩溃重放自动幂等，天然 exactly-once；无需 Kafka 事务、无需分布式锁。这是所有 JVM 工具结构上做不到的简单解法。

全量与增量的接缝，怎么才算对

PostgreSQLpg_export_snapshot 建立一致性快照 → 建 slot → 并行分块读（PK 区间/ctid），块级断点 → 快照结束、切 WAL，LSN 对齐零空洞
MySQL毫秒级取位点（FTWRL 或 8.0 LOCK INSTANCE FOR BACKUP）→ START TRANSACTION WITH CONSISTENT SNAPSHOT → 分块读 + binlog 位置对齐
无锁不锁表也不锁库：快照读走一致性读视图，只有取位点那一瞬需要协调
校验dbsync verify：分块 checksum + 抽样行比对，差异直接出「订正 SQL」而不是只报个红

难点提醒：这三步（一致性快照、位点对齐、断点续传）比性能难得多，也正是竞品的护城河。

五个目标，逐条对应手段

目标怎么做到验收数字
低开销零 GC 依赖、对象池复用解析缓冲、批量编码；不拖 Kafka常驻 <80 MB，空转 CPU <2%
低延迟group commit 窗口 1ms；不做中间落盘；单跳直连目标同机房 p99 <100 ms
高吞吐表/分片级并行 + 批量 COPY/多值 INSERT + 自适应批量单核 ≥2 万行/s，8 核打满万兆
快启动静态二进制、无 JVM、无外部注册中心；配置即代码冷启 <200 ms，二进制 <25 MB
易上手一条 yaml → dbsync run；plan 预演不写目标；verify 一句话校验30 秒内跑通第一个同步
dbsync plan   sync.yaml     # 只读预演：算什么、写哪里、预计多久
dbsync run    sync.yaml     # 全量+增量一体，Ctrl-C 即停，重启续跑
dbsync verify sync.yaml     # 分块校验，输出订正 SQL
dbsync status               # 一屏：延迟/吞吐/位点/队列/重试

MVP 边界（不做什么，比做什么重要）

阶段范围周期估计
v0.1PG→PG（含 DDL）、MySQL→PG；run/plan/verify/status；_ds_meta 幂等；内建 bench4–6 周
v0.2Kafka / NATS / Redis Streams / ClickHouse / ES 五种 sink + 映射 DSL3–4 周
v0.3Oracle LogMiner（只读）、达梦 DM8、金仓（走 PG 协议可复用通道）6–8 周，最硬
v0.4双向/冲突策略、分片并行消费、Prometheus + TUI看需求
不做可视化调度平台、流计算/聚合、SaaS 控制面、跨云托管。这些是 SeaTunnel 和商业产品的战场。
先内部吃掉：abjt 是金仓 + MySQL、ABT 是 MySQL 多服务、灵枢是 PG——三个真实库就在手上，v0.1 出来先拿它们 dogfooding，比找外部用户快得多。

风险，说在前面

  1. 生态已被占坑。PG 侧 PeerDB / pgstream / go-pq-cdc 都在；连接器广度打不过 SeaTunnel。切进去只能靠「国产库 + 一体 + 轻」。
  2. 正确性比性能难。大事务、DDL、类型漂移、断点续传，任何一个不严谨都会「看起来在跑但对不上账」。这块要拿真库 + 故障注入来验。
  3. 单人维护型项目活不久。要么自用（收益是省下商业授权与运维），要么一开始就想清楚维护者和发布节奏。
  4. DDL 同步是分水岭。只同数据不同结构的工具，半年后一定被放弃。

等你拍三件

  1. 定位：自用基础设施（先吃掉 abjt/ABT/灵枢三条链）还是对外开源产品？两者对「连接器广度」的投入完全不同。
  2. 语言：认可 Go 主干（Rust 留作后续热路径）？还是要一步到位全 Rust？
  3. 第一刀切哪里：PG→PG（最快出活）／MySQL→PG（你现有系统最多）／直接啃达梦+金仓（客户价值最高、最难）。

建议 自用起步 · Go · 先 PG→PG + MySQL→PG 打通接缝，金仓复用 PG 通道当 v0.1 的惊喜项。