搞数据同步的人大概都有过这种经历全量数据好不容易导完增量延迟也追到了毫秒级你松了一口气正准备宣布迁移成功业务方却丢过来一张对账报表里面躺着几千条源头有、目标没有的记录。那一刻你就会明白异构数据同步这件事延迟只是最容易被看到的指标真正难的是把每一笔账都守住。这篇文章想聊的就是用我们自己基于 Kafka 落地的一套同步框架 KFSKafka-based Sync Framework去处理“不停机迁移”这个场景下的数据一致性问题。所谓不停机迁移就是业务还在线上跑着源系统不能锁、不能停数据要完整搬到目标系统切流量时还不能丢账、不能重账。KFS 在中间扮演的角色不是一个简单的搬运工具而是一套带水位线、带对账、带回放能力的同步机制。它解决的核心问题不是“快不快”而是“准不准”。这篇内容适合正在做数据库迁移、实时数仓建设、异构存储同步的工程师尤其是被“延迟追平了但数据对不上”折磨过的团队。我会把 KFS 的整体设计、核心配置、切换步骤和踩坑经验都拆开讲清楚。1. 不停机迁移的真正难点延迟只是冰山一角1.1 先讲一段真实经历前两年我们做过一次 MySQL 到 ClickHouse 的迁移源端是核心订单库单表将近 3 亿行每天新增大概 800 万行。业务方的要求很明确不能停机每个订单都不能丢而且切换当天不能让运营感觉到任何异常。当时我们第一版方案很朴素用 DataX 导全量再用 Canal 监听 binlog 把增量灌到目标端。全量跑了大概四个小时增量也一度追到延迟只有几秒看起来一切顺利。结果在灰度验证阶段对账脚本一跑发现目标端比源端少了六千多条记录还有三百多条重复。六千多条记录对 3 亿行来说只是十万分之二但对业务方来说任何一条核心订单数据出问题都是大事。后来查了很久原因五花八门全量导出期间源端发生了 DDL导致导出任务部分分片失败被静默跳过增量阶段目标端写入偶发超时后重试但重试时走的是另一个没有幂等控制的写入通道还有一批 update 操作因为 ClickHouse 的 MergeTree 引擎更新语义和我们预期不一致被直接覆盖掉了。这些问题都有一个共同点延迟监控完全正常但数据的一致性在无人察觉的情况下悄悄破了。从那次之后我形成了一个判断不停机迁移的核心不是把延迟压到多少毫秒而是建立一套机制让每一条数据从源端到目标端的生命周期都可追踪、可校验、可回放。这就是后来 KFS 这套东西的起点。1.2 异构数据同步到底“异”在哪很多人理解的异构数据同步就是两边的表结构不一样做个字段映射就行。但真实业务里“异构”带来的麻烦远比字段映射复杂。首先是数据模型的差异。MySQL 里一张表可以有丰富的主键、唯一索引、自增字段而 ClickHouse 这类分析型数据库对更新和删除的支持是受限的。你用主键去 upsert 一套逻辑到目标端可能根本不生效必须靠 ReplacingMergeTree 或 CollapsingMergeTree 这类引擎自己去处理去重。一旦引擎配置不对数据就悄悄重了。其次是类型系统和语义差异。MySQL 的 decimal 到 ClickHouse 的 Decimal 要做精度控制MySQL 的 datetime 带不带时区到了 ClickHouse 的 DateTime64 要怎么转换源端 varchar 里不小心塞了一个特殊字符JSON 序列化会不会被截断这些都会被一并算入“异构”的范畴。再就是事务边界不同。MySQL 的一个事务在 binlog 里可能对应多条变更记录这些记录之间的业务完整性在源端是原子提交的。但到了迁移管道里它们被打散成一条条独立消息如果目标端写入失败一半、成功一半这个事务的原子性就没了。系统引擎不知道它只知道单条消息处理成功或失败。KFS 在设计初期就明确了一点它不是一个字段对字段的映射工具而是一条带有状态管理的同步管道。每条消息进入管道之后它的来源事务、位点、处理结果都必须有记录这样才能在“异构”的缝隙里找到可对账的依据。1.3 KFS 解决的是“账”的问题标题里我说“守住每一笔账”这里的“账”有两层意思。一层是业务账就是订单、流水、余额这类真实数据一笔都不能少、不能错。另一层是同步账就是 KFS 内部记录的数据流转账哪一批数据从源端抽出来了哪些增量已经消费了消费到哪个水位了校验结果是什么补偿任务执行了几次。业务账是否完整靠的就是同步账是否可追溯。这也是 KFS 和普通同步工具最大的区别。普通同步工具是“搬完就算完”KFS 则是搬完只是开始它还会持续比对源端和目标端把差异数据重新拉平甚至支持在一定时间窗口内做历史回放。用一句话概括KFS 把同步从“尽力而为”变成了“确认交付”。2. KFS 核心设计全量、增量、校验三线合一2.1 KFS 是什么KFS 是我们内部基于 Kafka 生态自研的一套同步框架全称 Kafka-based Sync Framework。它由四个组件组成KFS Agent 负责从源端捕获数据包括全量快照和增量变更KFS Channel 基于 Kafka 的 topic 作为数据通道KFS Controller 负责分配任务、记录水位线、管理消费进度KFS Verifier 负责周期性的数据校验和差异统计。说到底 KFS 没有发明什么特别牛的技术它更像是把一套迁移方法论固化成系统。Kafka 在这里承担的是缓冲和解耦的职责。为什么选 Kafka 不选其它消息队列因为我们要面对的是海量 binlog 事件Kafka 的吞吐量、消息堆积能力和消费位点管理机制都比较成熟。尤其是 Kafka 的消费者可以手动提交位点这意味着 KFS 可以在数据处理成功之后再提交消费进度天然适合“确认交付”的模式。但 Kafka 也带来一个问题它本身不保证消息不会重复。同一个消息在 rebalance 之后可能被重新消费这就要求 KFS 在写入目标端时必须有幂等控制。这个后面会专门讲。2.2 全量链路导出快照时不能影响业务不停机迁移最矛盾的地方在于你要导全部数据但又不能锁表。MySQL 的 mysqldump 如果不开一致性快照导到一半数据变了导出结果就是个逻辑混乱的集合。KFS 的做法是分片并行 一致性快照 增量补偿三步走。先讲分片。KFS Controller 会根据主键范围把大表拆成多个分片每个分片由一个 Agent 并发导出。分片的目的有三个一是提高导出速度二是降低单条连接的压力三是如果某个分片导失败了重跑这个分片就行不用全量重来。分片大小怎么定一般控制在 20 万到 50 万行之间或者按主键 ID 的 100 万分位一段。太小了任务太多调度开销大太大了单任务失败后的重试成本高。我们一般建议每片导出时间不超过 5 分钟。一致性快照这一步如果是 MySQL 8.0建议直接用 GTID SHOW CREATE TABLE 先拿到一份结构快照之后所有分片都在同一个 REPEATABLE READ 事务里做 SELECT。这样做的前提是数据库能撑住这个事务的 undo 膨胀所以一般放在业务低峰期启动全量导出或者从只读从库拉取快照。但快照再一致它也只是一个时间点的状态。从生成快照那一刻开始业务产生的所有增量变更都还没进目标端。所以全量链路一定会接一条增量补偿链路把快照位点之后的 binlog 变更补进去。2.3 增量链路用水位线代替时间戳增量同步最常被误解的概念就是“延迟”。大家习惯看“当前时间减去最后一条同步数据的时间”这个数字确实直观但它其实不能精确描述同步进度尤其在源端发生大事务或者 DDL 的时候。举个例子假设源端凌晨两点跑了一个大数据量批处理任务一口气更新了 5000 万行。binlog 事件按顺序进入 Kafka消费端一直接收到这些事件。如果用“最后一条数据的时间戳”算延迟因为批处理任务的数据写入时间在凌晨你会看到延迟是 0好像已经追平了。但实际上消费端还在处理两个小时前的那批历史数据业务实时产生的新数据排在后面根本没有被处理。这就是典型的“假追平”。KFS 不依赖时间戳判断进度它用的是水位线机制。Controller 会持续记录两件事一个是源端 Kafka 分区里最新一条消息的位点另一个是每个消费者组实际提交到目标端的位点。两者之间的差值才是真正的消费缺口。这个数字和时间没有直接关系它只代表“还有多少条消息没有被处理完”。补进来之后增量同步的延迟监控就会分成三个层次端到端延迟业务写入源端到目标端可见、捕获延迟源端产生到进入 Kafka、消费延迟进入 Kafka 到写入目标端。KFS 的控制台会同时展示这三个指标出现异常时可以快速判断瓶颈到底在哪一段。2.4 校验链路迁移的“审计日志”校验不是迁移结束之后才做的事而是从全量导出阶段就开始持续运行的。KFS Verifier 做的事情是周期性从源端和目标端各取一组数据按分片或按主键范围做比对记录差异数量。校验有全量校验和抽样校验两种。全量校验适合单表数据量在千万级以下或者已经确认关键路径比较稳定的情况抽样校验适合超大表可以按主键区间、按时间范围、按业务分片抽出一部分来做。我们的经验是迁移窗口内做全量校验迁移完成之后做定期抽样校验这样既能保证切换安全也能在后续运行中及时发现增量链路的潜在问题。校验数据的存储也很讲究。KFS Verifier 会把每一次校验的差异记录写入一张独立的校验审计表内容包括源端位点、目标端主键、差异类型源有目标无、源无目标有、字段值不一致以及发现时间。这张审计表的价值在于它让数据同步这件事变得可以复盘。业务方问“这条数据为什么不对”的时候你能直接翻出校验记录而不是靠嘴解释。3. 实操用 KFS 跑通一次 MySQL 到 ClickHouse 的不停机迁移3.1 环境拓扑与版本先说我们这次迁移的拓扑。源端是 MySQL 8.0.28共三套分库每个分库核心业务表 3 亿行目标端是 ClickHouse 22.8 集群三节点中间是 Kafka 2.8 集群三个 broker核心 topic 分区设置为 24 个。KFS Controller 部署在两个节点上通过选举保证高可用。为什么选用 ClickHouse 作为目标因为业务场景是数据分析平台订单数据进了 ClickHouse 之后要做多维聚合查询。MySQL 保留近 90 天的热数据90 天以前的数据会被归档到 ClickHouse 里做长期分析。所以这次迁移实际上是把已有历史数据一次性导入 ClickHouse并保持后续每天的新增数据持续同步。这个场景对强一致性要求没那么苛刻因为 ClickHouse 本身不是交易系统但也不能接受丢数据。业务方期望的是“数据可以稍有延迟但最终必须完整”。这也是 KFS 最擅长的场景。3.2 关键配置与参数选择KFS 用一份 YAML 配置来描述同步任务。下面是一个简化的配置示例我把关键字段都加了注释sync_task: name: order_center_to_clickhouse source: type: mysql hosts: - 10.0.1.10:3306 - 10.0.1.11:3306 - 10.0.1.12:3306 username: kfs_user password: ****** include_tables: - trade_order - order_item binlog: # 全量导出开始时的 binlog 文件名和位点 start_file: mysql-bin.000018 start_pos: 123456789 channel: type: kafka brokers: 10.0.2.10:9092,10.0.2.11:9092,10.0.2.12:9092 topic_prefix: sync_order_center partition_count: 24 # 消息体使用 Avro 编码带 schema 演进能力 serializer: avro target: type: clickhouse hosts: 10.0.3.10:8123,10.0.3.11:8123,10.0.3.12:8123 database: analytics # 全量导入时的写入并发数 bulk_insert_concurrency: 12 bulk_insert_batch_size: 20000 # 目标表引擎采用 ReplicatedReplacingMergeTree merge_engine: ReplicatedReplacingMergeTree sync_mode: # 三步全开全量、增量、校验 enable_full_dump: true enable_incremental_sync: true enable_verifier: true # 达到多少秒延迟后触发告警 latency_alert_threshold_s: 30 watermark: # 全量任务达到这个位点之后才开始追增量 full_dump_watermark_topic: sync_watermark sync_interval_ms: 5000这里有两个参数需要重点解释。第一个是partition_count。Kafka topic 的分区数决定了消费的并行度。24 个分区对应 24 个消费线程在我们这个规模下比较合适。分区数太少消费速度跟不上 binlog 产生速度分区数太多Kafka 自身和 ClickHouse 的连接数压力会增大。如果你拿不准可以先按“QPS 峰值 / 单分区消费能力”来粗算单分区消费能力我们实测在 3000 到 5000 条每秒之间然后在这个基础上留 30% 到 50% 的冗余。第二个是bulk_insert_batch_size。ClickHouse 批量写入不是越大越好。批量太大单次写入占用内存多失败后重试代价也大批量太小ClickHouse 的合并压力会很高。我们的经验值是一批 2 万到 5 万行具体要根据字段数量和平均行宽调整。KFS Controller 会定期把当前消费位点写入到 Kafka 的一个专用 topic 里这个 topic 就是水位线记录的载体。Controller 挂了之后新的 Controller 启动时会从这个 topic 读取上次的消费进度继续执行不会丢位点。3.3 切换过程先灰度再全量切换不停机迁移的切换我坚决不建议一次性把流量全部打过去。KFS 的推荐做法是至少分三步走。第一步保持源端单写目标端开启同步。这个阶段全量已经导完增量持续在跑KFS Verifier 周期性做全量校验。你把业务查询流量按 1% 的比例灰度切到目标端对比查询结果和响应时间。如果发现目标端数据有缺失可以直接回滚因为源端仍然是唯一写入方业务没有受到任何影响。第二步当灰度查询连续 3 天校验通过率都是 100%且延迟 P99 低于 5 秒时可以进入双写阶段。双写就是同一笔业务数据同时写入源端和目标端。这个阶段的关键是写入幂等目标端的写入必须以业务主键为准做 upsert否则双写和 binlog 同步同时生效会制造重复数据。第三步双写稳定运行一段时间后把读流量全量切到目标端源端只保留写入能力。最后再把源端的写流量也切到目标端源端进入只读状态等待业务方确认无误后退出。这里有一个很容易被忽略的细节双写阶段切换读流量之前一定要把增量同步的补数任务再完整跑一遍确保目标端数据已经落后源端不超过 5 秒。否则用户刚切过去看到的可能就是上一分钟的数据。4. 每一笔账怎么守幂等、对账与补偿4.1 目标端的幂等设计不停机迁移过程中数据重复几乎是不可避免的。Kafka 的 at-least-once 语义、消费端 rebalance、网络重试、双写与 binlog 同步并存这些因素任何一个都能导致同一条数据被写入目标端多次。如果目标端没有幂等能力账就乱了。ClickHouse 的幂等策略主要靠表引擎。我们用的是 ReplicatedReplacingMergeTree配合版本字段来实现“同主键保留最新值”。具体做法是在建表时增加一个版本列KFS 将 binlog 中的事务时间戳或一个全局自增版本号写入这个列。ClickHouse 在后台合并时遇到相同主键会保留版本号最大的行。KFS 的 Agent 在写入目标端之前会先把源端的 binlog 事件按主键做一次本地去重。比如同一个事务里对同一行数据修改了三次KFS 只需要把最后一次修改的结果写到目标端这样可以减少目标端的合并压力。如果 binlog 事件跨了事务KFS 就按“版本号大的覆盖版本号小的”原则处理最终一致性是由目标端的合并算法保证的。对 MySQL 这类传统数据库做目标端时幂等就更直接了主键冲突就用INSERT ... ON DUPLICATE KEY UPDATE基本不会出问题。真正容易出问题的是那些没有主键的表这种表在同步时最好给 KFS 配置一个“附加主键”的规则比如用多列拼接作为逻辑主键否则对账和去重都无从谈起。4.2 对账怎么做才有说服力对账最怕的就是两边各算各的最后数字对不上还找不到原因。KFS Verifier 的对账逻辑分三层数量对账、抽样明细对账、热点值对账。数量对账最简单源端执行SELECT count(*) FROM trade_order WHERE update_time ?目标端执行同样的条件统计比较两个 count。但数量对账有个致命弱点如果源端和目标端的数据一致但都少了一批count 可能还是相等的。所以它只能作为快速筛查不能作为最终结论。抽样明细对账是真正有说服力的。KFS 会按照主键的散列值抽样例如抽主键% 100 5的数据分别从源端和目标端查出来逐字段比对每个字段的哈希值。这个维度能捕捉到“行数相同但内容不同”的隐蔽问题。热点值对账是针对特定业务场景设计的比如用户 ID、订单状态、金额分布这类关键维度单独跑一轮分组统计做比对。我们在实际迁移中发现数量对账和抽样明细对账都通过了但热点值对账发现了 18 条数据的目标端金额字段和源端不一致——这是源端 decimal 精度映射到 ClickHouse 时小数位被截断导致的。4.3 补偿机制从死信队列到人工订正KFS 的每条消息处理都有一个状态流转成功、失败、补偿中、已放弃。处理失败的消息不会简单被丢弃而是进入死信队列。Controller 会定期扫描死信队列按照配置的重试策略重新投递。重试策略我们一般这样设置前 5 次重试间隔分别为 1 秒、5 秒、30 秒、5 分钟、30 分钟。超过 5 次后消息进入待人工处理队列同时告警通知到值班群。最让工程师头疼的一类问题是“重试永远成功不了”。比如目标表结构改了导致字段长度不够或者源端字段里有非法字符到目标端怎么都插不进去。遇到这种情况靠系统重试是没用的必须人工介入。KFS 提供了一条手动订正的 API可以让工程师直接查看死信消息的完整 payload修改之后重新投递或者直接跳过并记录原因。我们的经验是迁移期间要安排专人盯死信队列每两小时清一次。死信队列堆积太久说明链路上有一个结构性错误没有解决这种时候强推重试只会制造更多的脏数据。5. 常见问题与排查技巧实录5.1 问题速查表先给你一张可以直接抄的排查表都是我们实践中反复踩过的问题。症状可能原因排查手段解决办法延迟一直追不平全量导出的 binlog 位点不对增量从旧位点开始消费查看 Controller 记录的消费位点和 Kafka 最新位点重置消费组位点到全量开始位点Kafka 消费组频繁 rebalance单条消息处理时间太久超过了 max.poll.interval.ms查看消费者日志和每分钟消费条数增大单次 poll 批次提高并发线程数对账发现目标端多了数据双写阶段和 binlog 增量同时写入幂等配置失效查看目标表是否设置了版本列在表引擎中增加版本字段对账发现目标端少了数据全量分片任务有失败被静默跳过查看 KFS 任务列表的分片状态补跑失败分片ClickHouse 查询性能下降大批量 insert 触发了过多 merge查看 merge 队列长度和分区数降低写入并发合并小分区源端 DDL 导致同步中断目标端表结构未同步更新查看错误日志中的 schema 不匹配信息手动执行 DDL 变更然后重放消息5.2 延迟突然飙升怎么排查延迟飙升是迁移期间最常遇到的“心脏病”级别问题。我自己的排查顺序是这样的。先看消费端有没有在消费。登录 Kafka 消费者组客户端执行kafka-consumer-groups --describe --group kfs_order_consumer看一眼每个分区的 LOG-END-OFFSET 和 CURRENT-OFFSET。如果 CURRENT-OFFSET 很久没动说明消费端卡住了去查目标端日志或者看是不是有锁表。再看是哪个环节卡住。如果消费端活跃但延迟在涨大概率是目标端写入慢。ClickHouse 这种数据库对批量插入比较友好但对单条插入很不友好。KFS 默认使用攒批模式如果单条消息轻量度太高比如一个事务里有一条大消息夹杂着几千条小消息写入 batch 会一直等大消息完成导致整体吞吐下降。这个场景下可以把 batch 等待时间调短一点让消费端把大消息和小消息分开处理。还有一种很隐蔽的情况源端执行了大事务binlog 产生量在短时间内暴增Kafka 消息积压是正常的。这时候不要慌先算一下消费能力和积压量的对比确认能不能在目标时间内消化完。如果确实消化不完再考虑扩容分区数和消费者实例。5.3 校验对不上的几类原因与处理校验对不上的原因很多但归纳起来就三类源端数据变了、目标端写入有问题、校验逻辑本身有漏洞。源端数据变了一般是因为全量导出和增量同步之间存在时间窗口。比如全量快照是在 10:00:00 生成的而一条数据在 10:00:05 被更新了增量链路通过 binlog 捕获到了这条 update但目标端那条数据还停留在全量快照里的旧值直到增量消息被处理完才更新。如果校验刚好在 10:00:03 跑了一轮就会把这个时间差判成差异。这个问题不是 bug而是数据的时间语义问题。解决方法是校验时给数据加一个“有效时间窗口”只比较更新时间早于某个时间点的数据或者容忍一定时间内的差异。目标端写入有问题通常是字段映射或者类型转换的锅。我们遇到过一个案例源端字段是 varchar(64)但里面存了一个被截断的 JSON 字符串目标端用 JSON 解析函数去处理它结果解析失败消息被丢进死信队列。这种问题靠重试解决不了一定要从映射配置和字段内容两方向同时排查。校验逻辑本身有漏洞往往是最隐蔽的。有一次我们连续三天校验通过率都是 100%结果切换前一周发现目标端缺了一批数据。后来查出来那批数据的主键恰好不在抽样规则里——我们当时用的是主键% 100 5抽样但那批历史数据的主键全部是两位数取模后落在 0 到 4 区间的比例远低于 5%天然被抽样规则漏掉了。从那以后我们把抽样规则改成了主键按位异或后的散列值保证主键分布再奇怪也能均匀采样。6. 写在这轮迁移之后几点沉淀下来的经验这轮迁移做完之后我最大的感受是不停机迁移这个事技术方案的选择固然重要但更关键的是把“可验证、可回退、可追溯”这三条原则贯彻到每一个环节。KFS 帮我们解决的是工具层面的问题但在工具之上团队能不能坚持跑完整轮校验、能不能在延迟异常时冷静定位而不是盲目加资源、能不能在业务方质疑数据准确性时拿出审计记录这些才是决定迁移成败的底色。我个人现在的习惯是任何一条新的同步链路在正式上线前都会先搭一套模拟数据环境把全量、增量、校验三条链路完整跑一遍用脚本模拟源端的 update、delete、大事务、DDL 变更观察目标端在这些场景下的表现再把对账脚本固化进发布流程。这样真正面对生产环境的时候至少能保证“出问题的时候我们知道问题在哪”。数据同步这个领域没有银弹延迟追平不是终点每一笔账都被守住才是。KFS 这套方案目前在我们内部已经跑了好几条链路后续如果有更深入的对账策略和补偿机制优化我再来更新。希望这篇拆解能帮你少踩几个坑。