Skip to main content

企业级数据库同步平台选型报告

第一章 项目背景​

1.1 业务场景​

本项目建设方运营着一支由近200艘船舶组成的远洋船队，每艘船舶均部署有本地业务系统与MySQL数据库。船舶通过卫星、4G/5G等无线链路与岸上数据中心连接，存在以下典型特点：

  • 网络不稳定：海上信号频繁抖动，带宽窄、延迟高（RTT常达600ms~2s）。
  • 长时间断网：船舶航行至远洋无信号区域时，可能断网数小时甚至数天。
  • 多节点对等：每条船是一个独立站点，需要与岸上中心及其他船舶之间进行数据交换。
  • 双向同步需求：业务要求船岸之间支持双向数据同步，例如订单(Order)表需要双向同步，日志(Log)表仅从船到岸，配置(Config)表仅从岸到船。
  • 数据最终一致：允许在断网期间两端各自写入，网络恢复后自动达成最终一致。
  • 可配置同步策略：需要能够按数据库、表、甚至行级别精细控制同步方向和冲突解决策略。
海上船舶 (Ship001, Ship002, ...)
      │
      │ 卫星 / 4G / 5G (高延迟, 低带宽, 易中断)
      │
岸上数据中心 (Shore DC)
      │
MySQL  <──────> MySQL

1.2 现有系统​

目前系统采用 Dotmim.Sync 框架实现船岸数据同步：

Dotmim.Sync (C# 库)
     │
     ▼
MySQL (船端/岸端)
     │
     ▼
HTTP 传输 (同步方式)
     │
     ▼
MySQL (对端)

运行中暴露的问题：

  • 可扩展性不足：Dotmim.Sync 设计为嵌入式库，缺乏中心化的节点管理、配置分发和监控能力，当船舶数量增加至上百艘时，运维复杂度急剧上升。
  • 运维困难：没有图形化管理界面，排查同步异常需要直接查询数据库 Scope 表，效率低下。上线、升级、配置变更都需要重新发布应用。
  • 冲突处理不足：内置冲突解决策略主要为 Last Write Wins 和自定义存储过程，缺乏基于节点优先级、时间戳向量等高级策略，难以满足复杂业务规则。
  • 配置中心缺失：所有同步范围(Scope)、过滤条件、映射关系均硬编码在代码或本地配置文件中，无法集中管理和动态下发。
  • 监控能力不足：缺乏同步延迟、批处理吞吐、传输成功率、异常数量等关键指标的可视化监控与告警。
  • 二次开发成本高：框架源码虽开源，但模块耦合度高，要扩展为平台级系统需要大量侵入式改动，升级上游版本时合并困难。

1.3 建设目标​

建设 企业级数据库同步平台，对船岸数据同步进行统一管控，支撑未来5年的业务发展与技术演进。

平台需具备以下核心特性：

  • ✓ 支持 MySQL 作为主力数据库，预留 PostgreSQL 接入能力
  • ✓ 原生支持 双向同步，并可按表级、行级定义方向
  • ✓ 提供 配置中心，集中管理所有节点的同步范围、映射、过滤、冲突策略
  • ✓ 实现 节点管理，包括注册、健康检查、版本管理、在线升级
  • ✓ 具备 弱网恢复 能力：断点续传、Checkpoint、自动重试、ACK机制
  • ✓ 构建 企业级监控：Dashboard、Metrics、Alert、审计日志
  • ✓ 支持 在线升级 与灰度发布，最小化对业务影响

第二章 功能需求​

2.1 同步方向​

平台必须支持为每张表独立配置同步方向：

  • 双向同步：船 ↔ 岸（如订单表 orders，两地均可增删改）
  • 仅上传：船 → 岸（如操作日志表 operation_logs）
  • 仅下发：岸 → 船（如系统配置表 sys_config、基础代码表 base_code）

2.2 同步粒度​

同步范围支持多层次定义：

  • Database：整个数据库实例所有表（粗粒度）
  • Schema：指定 Schema 下所有表（适用于多租户）
  • Table：指定特定表
  • Row：按 WHERE 条件过滤行，例如 WHERE ship_id = 1
  • Column：只同步部分列（字段映射与裁剪）

2.3 同步策略组合​

典型业务配置示例：

表名方向过滤条件冲突解决
orders双向无岸端优先
operation_logs船→岸无无（仅插入）
sys_config岸→船无岸端覆盖
cargo_tracking双向WHERE vessel_id = {{node_id}}时间戳最新
user_profiles双向无自定义存储过程

2.4 字段映射​

支持异构表间的字段映射，应对船岸表结构微小差异：

Ship 表: cargo_tracking
  ─ cargo_name
  ─ weight
  ─ last_update

Shore 表: cargo_tracking_shore
  ─ name (← cargo_name)
  ─ weight
  ─ last_modified (← last_update)

映射规则需在配置中心定义，由 Agent 动态加载。

2.5 DDL 同步​

支持有限度的 DDL 同步，需评估风险后开启：

  • 支持：ALTER TABLE ADD COLUMN（新增可空列、带默认值列），CREATE TABLE（新业务表）
  • 不支持：DROP TABLE、ALTER TABLE DROP COLUMN（默认禁用，需人工审核）
  • 所有 DDL 语句在中心审批后广播至相关节点。

2.6 冲突检测与解决​

平台需提供可扩展的冲突解决框架：

策略描述
Last Write Wins基于时间戳，最后到达的变更覆盖旧值（依赖时钟同步）
Node Priority预定义节点优先级（如岸端优先级高于船端），冲突时保留高优先级
Version Vector每行维护版本向量，自动检测真正冲突并调用解决器
Timestamp类似 LWW，但采用数据库提交时间戳而非到达时间
Custom Resolver用户提供存储过程或插件，根据业务字段（如状态机）决策

第三章 非功能需求​

3.1 网络适应性​

  • 长时间断网恢复：支持断网7天后，恢复后存量变更不丢失、不重复（幂等）。
  • 自动重试与ACK：每条消息需有 ACK 确认与重试队列，指数退避。
  • Checkpoint 机制：按表、主键范围记录同步进度，断点续传，避免每次都全量扫描。
  • 数据压缩：支持传输前 Zstd/LZ4 压缩，节省昂贵的卫星带宽。

3.2 性能指标​

  • 吞吐量：单节点处理能力 > 1,000 TPS（事务每秒），可水平扩展。
  • 每日同步量：系统整体支撑 > 100万条变更/天，峰值 5000 TPS。
  • 规模：同时服务 200 艘船舶节点，未来可扩展至 500 节点。

3.3 可靠性​

  • 数据一致性：最终一致，冲突回执率 < 0.01%（网络正常下）。
  • 平台可用性：管理平面 99.99%，同步通道不受管理平面短暂故障影响。
  • 数据安全：传输过程 TLS 1.3 加密，节点认证基于 Token/证书，审计记录所有同步操作。

3.4 可运维性​

  • 集中管理控制台：Web Dashboard，查看所有节点状态、延迟、队列积压。
  • 健康监控：Prometheus Metrics + Grafana 告警，覆盖同步延迟、错误率、传输量。
  • 审计日志：记录配置变更、DDL操作、异常冲突解决过程。
  • 在线升级：Agent 灰度更新，支持金丝雀发布和回滚。

第四章 数据同步技术基础​

本章面向评审委员会，介绍主流数据库同步技术及其适用性。

4.1 Change Data Capture (CDC)​

通过数据库日志（如 MySQL binlog、PostgreSQL WAL）捕获行级变更，实时性强、对源库侵入小。缺点是要求数据库开启日志，存储和解析有一定开销。代表工具：Debezium、Canal、Maxwell。

4.2 触发器 (Trigger)​

在源表上创建 AFTER INSERT/UPDATE/DELETE 触发器，将变更写入影子表。实现简单，但与业务耦合高，影响源库性能，大数据量下成瓶颈。适合简单场景，不适合高吞吐平台。

4.3 时间戳/版本号​

依赖表中 last_modified 或 version 字段进行增量查询。实现极简，但要求业务表必须有相应字段，且难以捕获 DELETE（需软删除标记）。适合只增不改的日志表。

4.4 快照对比​

定期对源和目标进行全表扫描，计算差异并修复。耗时、资源重，仅作为最终一致性校验手段，不适合实时同步。

4.5 Binlog 解析（MySQL）​

利用 MySQL binlog (ROW 格式) 可精确捕获 INSERT/UPDATE/DELETE，包含完整的前后镜像。结合 GTID 可实现精确位点管理，是目前企业级 MySQL 同步的首选技术。

4.6 队列化传输​

将变更事件放入消息队列（Kafka、RabbitMQ、内置队列），实现异步、解耦、背压控制和持久化。CDC 采集端与写入端独立扩展，是弱网可靠的保障。

推荐路径：CDC（Binlog） + 队列 + 策略引擎 + 目标写入，实现低侵入、高吞吐、易管控的同步平台。

第五章 候选产品分析​

5.1 Dotmim.Sync​

简介：一个 .NET 库，支持多种数据库的同步，采用 Scope 定义同步范围，通过 HTTP 或直接数据库连接进行同步。架构为 Hub-Client 模式。

架构：

SyncAgent
  └─ LocalOrchestrator (源端)
       └─ RemoteOrchestrator (远程端)
            └─ Provider (MySQL, SQL Server, etc.)

通过 Tracking 表记录每行变更，依赖时间戳和 Tombstone 表。

优点：

  • .NET 技术栈，现有团队熟悉
  • API 简洁，上手快
  • 支持多数据库（MySQL, PG, SQL Server）

缺点：

  • 缺乏中心化管控和 UI
  • 冲突处理策略单一，仅 LWW 和简单自定义
  • 无消息队列，传输中断需整个 Scope 重传
  • 扩展为多节点平台需大幅二次开发
  • 社区活跃度一般，发布周期不稳定

适用场景：嵌入式、少量节点的简单同步，不适合 50+ 节点的企业平台。

评分：★★☆☆☆ (作为平台基础)

5.2 SymmetricDS​

简介：开源、跨数据库的异步数据同步平台，专门为弱网、多节点场景设计。采用 Node - Router - Channel - Trigger - Batch - Transport 六层架构。

核心架构：

Node (船/岸)
  └─ Router (决定数据去向)
       └─ Channel (同步通道，定义方向、优先级)
            └─ Trigger (基于触发器或变化捕获)
                 └─ Outgoing Batch (批次打包)
                      └─ Transport (HTTP/HTTPS, 压缩, 重试)
                           └─ Incoming Batch (对端接收)
                                └─ Conflict Resolver

数据变更由触发器捕获到 SYM_DATA 表，按时间批次打包，压缩传输。支持断点续传、ACK、多种冲突解决器。

优点：

  • 原生支持多主、双向、分级拓扑
  • 内置配置中心（通过 SYM_NODE_* 表），可通过 SQL 或 REST 管理
  • 强大的弱网适应：自动重试、离线缓冲、Checkpoint
  • 丰富的冲突策略：源优先、目标优先、新胜旧、自定义 Bean
  • 支持数据过滤、字段映射、路由表达式
  • 监控 REST API + JMX，可对接 Prometheus
  • 社区活跃，企业版有商业支持

缺点：

  • 基于触发器的捕获对源库有性能影响（但可通过变更表+时间戳替代）
  • 部署模型较传统，需 Java 运行环境
  • 批处理模式下秒级延迟，非真正实时流

适用场景：多节点、弱网、双向同步的企业级需求，高度匹配本项目。

评分：★★★★★

5.3 Debezium​

分析：Debezium 是基于 Kafka Connect 的 CDC 工具，读取数据库 binlog/WAL 并写入 Kafka Topic。

为什么不选作同步平台：

  • 仅仅解决“采集+传输”，不包含同步方向控制、配置中心、冲突解决
  • 依赖全套 Kafka 基础设施，船端部署 Kafka 过重
  • 不支持双向同步逻辑，需在消费端完全自研
  • 适合数据集成、数据湖，非端到端同步平台

评分：★☆☆☆☆ (作为组件参考，非平台)

5.4 Canal​

分析：阿里巴巴开源的 MySQL binlog 解析器，输出变更流到客户端。

为什么不选作同步平台：

  • 仅提供 binlog 解析和简单的客户端消费，缺少同步管理能力
  • 需要自己实现队列、传输、冲突、监控等全套机制
  • 维护力度弱（近两年更新极少），社区逐渐衰退

评分：★☆☆☆☆ (可作为 binlog 采集组件候选)

5.5 Tungsten Replicator​

分析：高性能的异构数据库复制引擎，使用 Tungsten 自研格式。多用于 MySQL → 数据仓库、异构复制。

缺点：

  • 架构复杂，部署运维门槛高
  • 对双向多主支持不成熟，更适合单向复制
  • 社区版功能有限，企业版收费昂贵

评分：★★☆☆☆

5.6 完全自研平台​

优点：

  • 完全掌控，贴合业务
  • 可渐进式演进

成本与风险：

  • 至少需要 4-6 人的资深团队投入 1-2 年
  • 弱网可靠性、冲突解决需要大量测试和场景打磨
  • 长期维护成本高，人员变动风险大

结论：当前阶段不推荐完全自研，应在成熟开源产品上构建企业级能力。

第六章 核心产品源码分析​

6.1 Dotmim.Sync 源码剖析​

核心流程：

  1. SyncAgent 发起同步请求，加载 SyncConfiguration (Scope 定义)。
  2. LocalOrchestrator 通过 Tracking 表获取本地变更，打包成 SyncContext。
  3. 通过 WebServerOrchestrator (HTTP) 或直接 RemoteOrchestrator 发送变更。
  4. 远程端应用变更，利用 ConflictManager 处理冲突，默认为 ServerWins。
  5. 将远程变更发回，本地应用更新 Tracking 表。

关键短板：

  • 传输为同步 HTTP Request-Response，无断点续传，弱网下每次重传整个 Scope。
  • Tracking 表基于时间戳，没有可靠位点(如 binlog GTID)。
  • 所有配置在代码或 XML，缺乏动态加载接口。
  • 扩展 ConflictManager 需写代码并重新编译部署。
  • 测试覆盖率低，部分异常路径未覆盖。

6.2 SymmetricDS 源码剖析​

基于 Java，模块划分清晰：

  • symmetric-core：核心引擎，包括路由(DataRouter)、通道(Channel)、数据服务(DataService)。
  • symmetric-io：负责序列化、压缩、传输协议，HTTP 与 TCP 实现。
  • symmetric-db：数据库抽象，支持多种方言。
  • symmetric-trigger：触发器生成与变化抓取。
  • symmetric-sync：主入口 SymmetricEngine，协调各模块。
  • symmetric-web：REST API、管理控制台基础。

数据流：

Trigger/Router → sym_data → Outgoing Batch (sym_outgoing_batch)
→ Extract → Transport → Incoming Batch (sym_incoming_batch)
→ Load → Conflict Resolve → Target Table

每张表可定义 Channel，决定方向、优先级、数据有效时间、重试策略。

扩展机制：

  • 提供 IExtensionPoint 接口，可在加载、路由、传输、冲突解决等环节注入自定义逻辑。
  • 配置全部存储在数据库，支持通过 SQL 或 REST 在线修改，实时生效。
  • 数据库设计规范，核心表如 sym_node, sym_router, sym_trigger, sym_channel，二次开发易理解。

源码质量：

  • 单元测试覆盖率高，JUnit 测试用例数千个。
  • 发布节奏稳定，约季度发布小版本，社区 issue 响应及时。
  • 代码注释详细，适合企业长期维护和 Fork。

第七章 企业级能力对比矩阵​

能力Dotmim.SyncSymmetricDSDebeziumCanal自研平台
双向同步✓✓××✓(需开发)
配置中心×✓(数据库)××✓
节点管理×✓(注册/监控)××✓
冲突处理一般很强无无定制
持久队列×✓(内嵌)✓(Kafka)×✓
断点续传弱✓(批次CK)✓(Offset)×定制
ACK/重试一般✓(完善)✓(Kafka)×定制
弱网适应差优秀一般差可设计
监控运维需自建REST/JMXKafka生态无需全自建
安全机制Token密码/HTTPSSSL/SASL无定制
异构映射✓✓(路由+转换)××定制
二次开发需重构插件化组件组件全掌控

结论：SymmetricDS 在企业级同步领域能力最为完备，与项目需求匹配度最高。

第八章 PoC（概念验证）方案​

8.1 目标​

验证 SymmetricDS 在模拟海事情景下的稳定性、性能及功能满足度。

8.2 环境准备​

  • 两台服务器，安装 MySQL 8.0，模拟船端(带宽限制 1Mbps, RTT 500ms, 5% 丢包率)和岸端。
  • 部署 SymmetricDS 3.15 版本，船岸各一个 Node。
  • 初始化测试库，包含订单表、日志表、配置表，规模 100 万行。

8.3 测试场景​

场景操作预期结果
1. 初始全量同步从岸端装载 100 万行订单数据船端在 10 分钟内完成初始加载
2. 日常增量同步船端以 100 TPS 写入订单，岸端查询验证延迟 < 10s，数据一致
3. 2小时断网恢复断开船岸网络，船端继续产生 5 万条变更恢复后 5 分钟内自动同步，零丢失
4. 双向冲突船岸同时修改同一条订单状态按策略（岸优先）正确解决，冲突记录可查
5. DDL 操作岸端 ALTER TABLE ADD 列经审批后船端成功同步 DDL
6. 批量更新岸端更新 10 万行数据船端在可接受时间内完成，吞吐监控可见
7. 节点故障恢复船端 MySQL 重启，SymmetricDS 停止 30 分钟启动后继续从检查点同步，无误

8.4 成功标准​

  • 所有测试场景通过。
  • 船端资源消耗 CPU < 20%，内存 < 2GB（除数据库本身）。
  • 网络带宽在压缩后平均 < 50KB/s（日常负载）。
  • 监控指标完整，可对接现有 Prometheus。

第九章 推荐方案​

短期（0-3个月）​

  • 完成 SymmetricDS PoC，验证关键场景。
  • 搭建中心管理控制台原型（基于 SymmetricDS REST API + Web 前端），展示节点状态与配置。
  • 输出 PoC 报告，确认技术可行性。

中期（3-12个月）​

  • 封装 SymmetricDS，形成标准化船端/岸端部署包（Docker 镜像）。
  • 开发企业级功能层：
    • 配置中心：可视化配置 Router、Channel、Trigger 等，写回 SymmetricDS 管理库。
    • 冲突管理界面：查看冲突记录，手动忽略或覆盖。
    • 监控告警：延迟超过阈值、错误率上升时自动通知。
  • 在 10 艘船舶试点，替代 Dotmim.Sync。

长期（1-3年）​

  • 根据运维反馈评估：
    • 若 SymmetricDS 扩展性和功能始终满足需求，持续在其上构建，贡献社区。
    • 若遇到无法克服的瓶颈（例如大规模节点下的批处理延迟、社区断更），则启动自研 CDC 同步引擎，继承积累的业务规则与管理界面。
  • 逐步拓展 PostgreSQL、SQL Server 支持。

当前决策：基于 SymmetricDS 构建企业同步平台，充分利用其成熟内核，聚焦企业级管控能力开发，缩短自研周期，降低风险。

第十章 企业同步平台架构（目标态）​

                           Web Console (React)
                                  │
                       ┌──────────┴──────────┐
                       │                     │
                 Node Manager            Policy Engine
                 (注册/健康/升级)         (冲突规则/方向/过滤)
                       │                     │
                       └──────────┬──────────┘
                                  │
                          Sync Controller
                       (REST API, 作业调度)
                                  │
          ┌───────────────────────┼───────────────────────┐
          │                       │                       │
     Ship001 Agent          Ship002 Agent          Ship003 Agent
  ┌──────┴───────┐      ┌──────┴───────┐      ┌──────┴───────┐
  │              │      │              │      │              │
Binlog    SymmetricDS   Binlog   SymmetricDS    ...    SymmetricDS
Reader   Engine(Mod)   Reader   Engine(Mod)          Engine(Mod)
  │              │      │              │      │              │
Queue          Queue   Queue          Queue   Queue          Queue
  │              │      │              │      │              │
Encrypt/Compress       ...                    ...
  │
HTTP/2 (Multiplex, ACK, Checkpoint)
  │
Shore Aggregator
  │
冲突处理 & 存储
  │
MySQL / PostgreSQL

Agent 核心流水线：

Binlog Reader (GTID) → 本地 Queue → 过滤/转换 → 压缩/加密 → 传输 → ACK → Checkpoint

平台在 SymmetricDS 基础上改造 Binlog 采集替换触发器，降低源库影响，并增强传输层多路复用，适应高并发船舶接入。

第十一章 源码二次开发难度分析​

维度SymmetricDSDotmim.Sync
模块划分清晰，核心/IO/DB/Web 分离，maven 多模块较清晰，但耦合于 .NET 同步管道
插件机制IExtensionPoint，支持自定义路由、加载、冲突等有限，主要通过继承 Provider 和 Orchestrator
数据库设计规范，100+ 张表，文档齐全简单 Scope 和 Tracking 表，适合单节点
配置中心数据库即配置中心，支持动态修改和热加载无，需自行设计
测试覆盖率高，自动化测试 CI 跑通中等，仅核心路径有测试
发布周期季度发布，稳定不定期，有时断更半年
Issue 响应较及时，核心贡献者活跃较慢，功能请求响应周期长
Commit 活跃度持续活跃，2025-2026 年仍高频提交2019-2022 活跃，近期减弱
长期 Fork 成本低，架构良好，可按模块覆盖高，需重构传输、配置、监控等模块

综合评分：SymmetricDS ★★★★★ （非常适合作为长期基础进行定制）
Dotmim.Sync ★★☆☆☆ （仅建议作为过渡组件）

第十二章 未来五年演进路线​

数据库支持演进​

2026 ── MySQL (全覆盖)
  │
2027 ── PostgreSQL (新业务、空间数据处理)
  │
2028 ── SQL Server (岸端部分遗留系统)
  │
2029 ── Oracle (外部合作方数据源)
  │
2030 ── 通用 CDC 平台 (多源多目标, 插件化)

平台能力演进​

消息队列 → 内置持久队列 (SymmetricDS) → 可选外部 MQ (Kafka/RabbitMQ) 支持
   │
CDC 采集 → 触发器 → Binlog Reader (自研或 Canal/Debezium 集成)
   │
数据服务 → 同步平台 → 数据枢纽 (DataHub)
   │
数据治理 → 数据质量、血缘、脱敏、合规审计

团队与生态​

  • 2026：组建 3 人同步平台小组，掌握 SymmetricDS 内核，构建 PoC 及首个管理控制台。
  • 2027：平台组扩展至 5 人，开始 PostgreSQL 适配和 Binlog 采集引擎研发。
  • 2028：同步平台成为部门级基础设施，对外提供自助接入，沉淀最佳实践。
  • 2030：孵化为企业级 CDC 平台，面向更多业务线和外部客户，建立开源/内部社区。

结论：本报告建议放弃继续深度定制 Dotmim.Sync 的路径，转而采用 SymmetricDS 作为核心同步引擎，向上构建企业级管控平面，在最短时间内补齐当前系统的短板。长期通过“开放核心 + 自研插件”的混合模式，实现技术自主可控，支撑未来多样化的数据库与业务场景需求。

在报告末尾增加以下参考文献和资源链接，可根据需要调整位置。

参考文献与资源​

候选产品官方站点与代码仓库​

  1. SymmetricDS

  2. Dotmim.Sync

  3. Debezium

  4. Canal

  5. Tungsten Replicator

数据同步技术参考​

  1. MySQL Binlog 与 GTID

  2. 弱网环境下的数据同步设计

  3. 冲突解决策略综述

企业级同步平台架构参考​

  1. Netflix Data Synchronization Platform (Keystone)

  2. LinkedIn Brooklin（异构数据同步）

  3. Alibaba Otter（基于Canal的同步管理系统）

运维与监控集成​

  1. Prometheus + Grafana

  2. TLS 1.3 规范

以上链接均为公开资源，截至报告编写时有效。建议在实际选型过程中定期查阅对应产品的最新文档与社区动态。