异构数据同步并行化实践：全链路并行的架构与调优

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

凌晨两点，我盯着同步延迟的监控面板。源端数据库的变更日志不断堆积，目标端数据库的CPU只跑到了35%。当时用的是默认的串行同步模式，一条链路把增量同步拖成了龟速。业务方等着割接窗口，数据却还在路上慢慢爬。

做迁移的兄弟应该都遇过这种情况。源库和目标库性能都不差，同步延迟就是降不下来。问题出在哪？今天从一次真实的迁移实战出发，把异构增量同步的并行化方案拆清楚。

异构增量同步，到底慢在哪

异构增量同步要做的第一件事是捕获源数据库的变更日志。解析后的变更需要转成目标库能理解的格式，再写入目标端。流程本身不复杂。麻烦的是传统同步工具大多用串行处理，一个变更事务处理完才能处理下一个。

源库每秒产生上千条变更的时候，串行链路就成了瓶颈。捕获、解析、转换、写入四个环节串在一起，整条链路的速度取决于最慢的那个。源端和目标端的硬件资源也都浪费了。源库多个CPU核心闲着，目标库磁盘IO没跑满，数据全在队列里排队。

怎么解决？思路很直接，把串行链路拆开，改成并行。我在实际项目里用过金仓异构数据同步软件Kingbase FlySync（简称KFS），它就是按这个思路设计的。不是简单开几个多线程复制，而是整条链路都并行化。捕获、转换、写入三个环节各自并行，环节之间还能流水线协作。作为对标OGG的异构数据同步方案，它要解决的核心问题就是在跨库迁移场景下实现秒级实时同步并保障数据一致性。

串行同步 vs 并行同步，差距有多大

先放一张对比表。

并行同步的优势不是某个环节快了，是整条链路都释放了。资源利用率上去，延迟自然下来。

全链路并行，KFS是怎么拆的

KFS的并行化不只是在写入端开几个线程。它把同步链路拆成三个独立并行的阶段，每个阶段内部都能水平扩展。

捕获阶段并行是关键第一步。源库的变更日志按事务ID或数据范围拆分，多个捕获线程各负责一段。这里有个底层设计值得注意。KFS在源端用了内存池做缓存层，增量日志捕获后先进内存缓冲，再由多线程并行解析。事务按提交顺序分配插槽编号，先提交的事务拿到小号插槽，并行解析时按编号顺序重组，保障业务一致性。源库产生的变更就能快速读取，不会在日志文件里越积越多。我之前听一个做运营商项目的同行聊过，他们那边源端日增量能到4.5TB，靠的就是这套并行解析加内存缓冲的架构，照样做到实时同步。数据量级一上去，这套设计的价值就体现出来了。

转换阶段并行解决的是格式适配。不同源库的日志格式差很多，Oracle的Redo Log、MySQL的Binlog、SQL Server的CDC各有自己的结构。KFS把转换任务分给多个转换线程，各处理各的那部分数据。转换逻辑互不干扰，效率翻倍。

写入阶段并行是最终落地。目标端KES数据库接收转换后的变更数据，多个写入线程按表级细粒度拆分，各自写入不同的目标表或数据分片。大事务不再卡住单一通道，多通道并行入库直接把目标库的CPU核心和磁盘IO都跑起来。目标库的多个CPU核心和磁盘通道都能用上。

三个并行阶段之间通过消息队列连接，形成流水线。捕获线程不用等转换线程处理完，转换线程不用等写入线程落盘。每个阶段只管自己的事，数据在队列里流转。

生产环境实测，并行同步到底能快多少

我在一个实际迁移项目里验证过KFS的并行效果。源库Oracle，目标库KES，数据量TB级，日均增量变更约两千万条。

先看串行同步的表现。单线程模式下，同步延迟稳定在15到20分钟。源端变更日志持续堆积，捕获线程的CPU跑满了，目标端还很空闲。按这个速度，割接窗口至少预留4小时以上。

切换到KFS并行同步后，并发线程数调到16。同步延迟降到30秒以内，峰值不超过2分钟。源库变更日志几乎实时清空，目标库CPU利用率从35%升到75%左右。割接窗口从4小时压缩到40分钟。

数据是监控面板上跑出来的。具体数字会因硬件和数据分布不同有差异，但数量级的差距是真实的。

并行同步还有个好处是故障隔离。串行模式下，一个大事务卡住，整条链路就断了。并行模式下，一个线程出问题，其他线程照样跑，不会全链路中断。

并行参数怎么调，给你一套决策框架

并行同步不是线程数越多越好。

调参的时候从4个线程起步，逐步增加，观察每个阶段的吞吐量变化。某个阶段的吞吐量不再随线程数增长，那个阶段就是瓶颈。这时候应该针对优化那个阶段，别继续加线程。

除了线程数，还有几个参数我在项目里调过，效果很明显。

先说入库吞吐。默认单次提交的数据量偏小，目标库频繁 commit，性能上不去。把这个值调大，commit 次数一下就降下来了。

# 单次提交数据量，默认10，我先试100
property=replicator.global.buffer.size=100

入库的批处理也要开。开启行事件优化，配合批次大小，小事务密集的场景提升特别明显。

# 开启行事件优化，单表一次入库1000行
property=replicator.applier.dbms.optimizeRowEvents=true
property=replicator.applier.dbms.maxRowBatchSize=1000

源端解析这边，优先用 Redo 方式。它对源端性能影响小，效率也高，RAC 这种特殊场景才用 Logminer。解析范围要控制，只同步必要的表，从源头减负。

# 只同步必要的表，减少无关解析
property=replicator.extractor.dbms.tablePatterns=SCHEMA.TABLE1,SCHEMA.TABLE2

内存池别省，设成服务器物理内存的 20% 到 30%。设小了，前面并行的优势发挥不出来。

最后说定位瓶颈。KFS 自带 fsrepctl perf 命令，服务在线时跑一下，能按阶段输出延迟。源端解析、网络传输、目标端入库，哪个阶段延迟大，瓶颈就在哪。比我前面说的"看吞吐量不再增长"更直接，调参前先跑一遍，别瞎调。

迁移同步避坑清单，这些坑我都踩过

做异构增量同步，有些坑踩了就后悔。我列几条你们注意。

别忽略事务一致性校验。并行同步时，多个线程写入目标库的顺序可能和源库不一致。KFS内置了事务顺序校验和按源端提交顺序重组的机制，实现并行写入的零误差保障。配置时记得在KFS参数中开启事务排序选项，并在割接前跑一次全量数据比对，确保上线后数据完全对得上。

大事务是并行同步的头号杀手。一个几百万行的批量更新事务，就算开了16个线程，也可能被分配到单个线程处理。建议在源库侧把大事务拆小，或者在KFS里启用大事务分片功能。

目标库的索引会成为写入瓶颈。并行写入时每个线程都在更新索引，索引维护开销成倍放大。同步阶段先禁用非必需索引，数据追平后再重建。写入速度能提升两三倍。

网络延迟经常被低估。源库和目标库跨机房部署时，网络延迟会成为链路瓶颈。KFS的队列缓冲区可以适当调大，但缓冲区太大会影响数据实时性。这个平衡点得自己测。

监控不能只看延迟数字。延迟只是结果，不是原因。要分别监控捕获线程的日志读取速率、转换线程的处理速率、写入线程的落盘速率。哪个环节慢了一目了然。

写在最后

异构增量同步不是把工具跑起来就完事。从串行到并行，从单点到流水线，每一步都得根据实际场景判断。KFS的全链路并行方案把同步链路拆成可独立扩展的阶段，资源利用率和延迟都能明显改善。这套方案在金融、医疗、制造、能源、政务这些行业都有落地，从GB级到TB级增量都能做到实时有序同步。

各位在迁移过程中还遇到过哪些同步难题？欢迎在评论区分享你的踩坑经验。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋