企业官网建设流程全解析

聊聊异构数据同步里最让人头疼的一致性问题，看看KFS是怎么做的

说到异构数据同步，做过这活的兄弟们肯定都知道，这事儿真不是搬砖那么简单。你把数据从Oracle或者MySQL搬到Kingbase，听起来好像就是个导出导入的过程。但其实呢，最让人心里没底的，往往不是速度慢，而是数据到底一不一致。今天咱们就借着金仓的KFS，好好掰扯掰扯这个事儿。看看它在“全周期数据一致性校验”这块，到底是怎么做到让人放心的。

一、异构数据同步里，为什么“数据一致性”这么难搞

很多时候，我们做数据同步，往往仅仅只是盯着进度条看。进度条跑完了，就觉得大功告成了。这是一个很危险的错觉。那为什么会这样呢？原因在于，你看到的进度条，往往只是代表“发过去了”，不代表“写对了”。

1.1 业务不停机的情况下，数据一直在变

现在企业层级里的系统，哪有那么容易给你停机窗口啊。基本都是要求7x24小时在线的。那么问题就来了。你在同步存量数据的时候，源端还在不断产生新的增量数据。

比如你正同步着一张一千万行的大表。同步到第五百万行的时候，源端有人把第十行的数据给改了。你同步完的时候，目标端拿到的是旧数据。这就不一致了。这种情况，如果你没有一个好的机制去比对和修复，上线后业务查出来的数据就是错的。这可是大事故。

1.2 存量数据和增量数据的割裂

通常来说，我们会分两步走。先全量同步存量，再启动增量同步抓取日志。但是这两步之间的衔接，是一个极易出错的点。

如果全量没导完，增量日志就开始抓了。中间这段时间的数据变更，很容易丢。或者全量导完了，增量回放的位点没对准，导致有些数据重复回放，有些没回放。这种割裂的情况，在传统的同步方案里，往往需要人工去对账。一张表一张表地去数。这工作量太吓人了。

1.3 传统的校验方式太笨重

那怎么校验呢？以前大家常用的办法，就是停机。先把源端停了，导出一份count，再导出目标端的count。两边一比。或者用一些MD5校验的工具，把两张表全扫一遍算哈希值。

这确实准。但是太慢了。而且你必须停业务。对于不能停机的系统来说，这就行不通了。你需要一种在线的、不中断业务的校验方式。这其实一直是行业里的一个痛点。

二、KFS的“低侵入、高性能”底座：不拖垮源库是第一步

在聊一致性校验之前，咱们得先说说KFS的底座。因为如果你连数据都同步不过来，或者同步过来慢得要死，那谈一致性就没意义了。KFS有一个很关键的特性，就是“低侵入、高性能”架构。

2.1 采集端的低侵入意味着什么

低侵入，也就是说，它在源端抓数据的时候，尽量不去打扰源端数据库的正常干活。它主要是解析数据库的日志，比如Oracle的Redo、MySQL的Binlog、Kingbase的WAL。

它不在源库里跑那种重查询。这对源端的性能影响就非常小了。毕竟你做同步，不能把原来的业务系统给搞挂了。这是底线。

2.2 目标端入库的性能瓶颈到底在哪

但是呢，源端抓得快没用。如果目标端写不进去，那整个链路还是会被卡住。这就是个典型的漏斗效应。

源端是怎么写的？可能是几百个连接在并发写入。但是同步工具到了目标端，往往是一个单线程在逐条回放SQL。这能快吗？肯定快不了。

这里面有几个很要命的瓶颈。
一个是网络往返。你发一条SQL，等数据库执行完返回结果，再发下一条。假设一次网络延迟是1毫秒。那六条SQL就是6毫秒。这时间全浪费在网上了。
再一个是小事务太多。源端每秒可能有好几千个小事务，每个都commit。这就导致目标端的磁盘IO被频繁的commit操作打满。
还有一个是单线程根本用不满多核CPU。现在的服务器都是几十个核的，你单线程跑，那99%的CPU都在睡大觉。

2.3 KFS是怎么把数据“存得快”的

为了解决这些瓶颈，KFS在目标端搞了一套很细的流水线机制。我画了个图，大家可以看看大概的流程。

它具体用了几个招数。
第一个是批量提交。它不是逐条发SQL了。而是把很多条SQL攒起来，打包成一次网络请求发给数据库。刚才说的六条SQL，现在只需要一次网络往返。这就快了很多。

第二个是小事务合并。这个挺有意思的。有时候一个事务里，对表1、表2、表3、表1、表2、表3这样交替操作。如果按顺序处理，每次切表都要重新做一次prepare。但是KFS会在内部做一个归并。它把同表的SQL挑出来放一起。这样表1的操作就连续了，只需要prepare一次。这又省下了大量的数据库解析开销。

第三个是Statement缓存。相同的SQL模板，它只解析一次，然后把执行计划缓存起来。后面遇到一样的，直接复用。这就大大降低了目标端数据库的CPU消耗。

这些底层的性能优化，其实是为了给后面的“0停机”和“在线校验”打基础的。因为只有你同步得足够快，你才有可能追上源端的变更，才敢谈在不中断业务的情况下去做校验。

三、重点来了：KFS的“全周期数据一致性校验”能力

好了，前面铺垫了那么多，现在进入正题。KFS在一致性这块，提出了一个“全周期”的概念。这是啥意思呢？

3.1 什么是“全周期”？存量加增量一起管

通常来说，大家做校验，往往是割裂的。全量导完比一次，增量跑一段时间再比一次。

KFS的全周期，是说它把存量数据的校验和增量数据的校验融在一块儿了。在存量同步进行的过程中，它其实就已经开始记录各种校验信息了。等增量同步接管之后，它会对新产生的增量数据，实时或者准实时地进行一致性比对。

它不是等所有事情都干完了才去算总账。而是边干边对账。这就好比你在点钞的时候，不是数完一大摞再复点，而是边数边核对。这样发现问题就能及时处理。

3.2 在线校验：业务不中断，CPU负载增加<3%是怎么做到的

这是KFS很牛的一点。它说它的在线数据校验，对源端性能影响极小，CPU负载增加不到3%。那它是怎么做到的呢？

其实你想想，如果你直接在源端跑一个SELECT COUNT(*)或者算MD5，那CPU肯定飙升，IO也肯定被占满。这肯定不行。

KFS的做法是，它不直接去扫业务表。它利用了同步链路本身已有的数据。在数据从源端抽取出来，还没发给目标端之前，它在内存里顺手就算了一下校验值。或者它在抓取日志解析出变更行的时候，就把这行数据的关键字段的哈希值给算出来了。

也就是说，它是把校验的计算逻辑，嵌在了同步的流水线里面。数据反正都要过这一遍，顺手算个哈希值，并不需要额外去读磁盘。这样对源端数据库的额外开销，就仅仅只是那么一点点CPU计算，几乎可以忽略不计。这就是为什么它能做到CPU负载增加小于3%。

对于存量数据，它也不是一股脑全扫。它是分批次、分段地去算。而且会根据源端的当前负载情况，动态调整校验的并发度和速度。如果发现源端很忙，它就慢点算。如果源端闲着，它就快点算。这就保证了在线校验不会去抢业务资源的饭碗。

3.3 发现差异后的“全自动数据修复”

光能发现问题还不算完。能自己把问题修好，那才叫真本事。

传统的工具，往往仅仅是给你出一份报告。告诉你：“表A的第100行不一致”。然后呢？然后你自己去查SQL，自己去目标端写UPDATE语句修。这在几百张表的情况下，人是会崩溃的。

KFS在这里做了一个“全自动数据修复”的功能。当它的校验模块发现源端和目标端某条记录不一样的时候。它会自动生成一条修正的SQL。比如源端是UPDATE了，但是目标端没同步成功，它就会拿着源端最新的这行数据，生成一条对应的UPDATE语句或者INSERT语句，直接在目标端执行。

这个修复是可以做到记录级的。精准定位到某一行，然后用正确的数据覆盖掉错误的数据。

而且它支持自动和手动两种模式。如果你对这个链路很有信心，你可以开启全自动模式。它发现差异就默默修掉，写个日志。这就真正实现了无人值守。如果你比较谨慎，你可以设置成手动模式。它把差异记录下来，你在界面上点一下确认，它才去修。这种灵活性，对于不同安全等级的项目来说，是非常实用的。

四、0停机平滑迁移背后的硬核技术支撑

前面说的全周期校验和自动修复，是建立在“数据能同步过来”这个前提下的。那么KFS是怎么保证0停机平滑迁移的呢？这就要回到它那个多通道并行入库的技术上了。

4.1 多通道并行入库解决串行天花板

刚才提到单线程入库太慢。KFS的做法是开多个通道。也就是启动多个线程，每个线程连着一个数据库连接，并行往目标端写数据。

但是这里有个大坑。多线程写，数据顺序怎么保证？你不能把UPDATE写到INSERT前面去吧。那数据就全乱了。

为了解决这个问题，KFS搞了一套非常细致的事件路由引擎。我给大家列一下它里面的几种策略，大家就能感受到这玩意儿有多细了。

最简单的是按源端的任务ID分。但这会导致同一张表的INSERT和UPDATE跑到不同线程里，肯定乱套。
接着是按哈希分。把同一个数据源的数据固定发到一个通道。这样同源有序了。但是如果是热点库，一个通道堵死了，别的通道闲着，这叫负载不均。
然后是轮询。按事务序号挨个分。这解决了负载不均。但是一个大事务有几十万行，把一个通道堵死，别的通道处理小事务很快干完了又闲着。
再然后是负载均衡策略。实时看哪个通道排队少，就发到哪个通道。这又破坏了“同表不能跨通道”的原则。

你看，每一种策略都在解决前一个策略的问题，同时又会引入新的问题。KFS没有搞一个所谓完美的方案，而是把这些策略全做出来，让用户根据实际情况去选。

对于特别大的事务，它还搞了个“事务拆分”。比如一个事务改了表1、表2、表3。它就把这个大事务拆成三个子事务。表1的去通道0，表2的去通道1。这样大事务就不会独占一个通道了。而且它还有“表亲和性”，保证后续的事务里，只要是表1的数据，就还发到通道0。这就保证了单表内的顺序。

更绝的是“行哈希”。如果是一个单表大事务，一张表写了100万行。它就根据主键值做哈希，把不同主键的行打散到不同通道。这样单表也能并行了。

4.2 断点记录与故障恢复：不丢数据的底线

并行通道多了，崩溃恢复就变得很复杂。假设有3个通道，通道0处理到了第100个事务，通道1处理到了第99个，通道2处理到了第97个。这时候进程挂了。重启之后，从哪里开始恢复呢？

如果都从97开始，那通道0和通道1已经提交的数据就会重复写入。
如果各自从各自的位置开始，那事务的完整性怎么保证？

KFS在这里维护了一个复合位点。它不仅记录每个通道处理到了哪，还记录了一个全局的提交计数。恢复的时候，它取所有通道位点的最小值作为安全起点。然后从源端把这个位点之后的数据重新拉过来。

接着它会做三段区间的判定。
对于已经确认提交过的事务，它直接跳过，不重复写。
对于在等待列表里还没提交的事务，它重新回放到对应的通道。
对于全新的数据，它正常处理。

这套机制，配合上它严格的DDL安全保护（DDL操作永远固定在通道0执行，不和同表的DML并发），就保证了即使在多通道高并发的情况下，一旦出现故障，数据依然能恢复到一致的状态，不丢不重。

五、实际案例印证：数据无忧不是一句空话

说了这么多技术细节，咱们还是得落回到实际业务里看看。

5.1 某省级政务云的实战情况

我之前了解过一个省级政务云的项目。那里面涉及到几十个委办局的几百套系统。要从Oracle和SQL Server同步到金仓。数据量是TB级别的，而且每天还有几百GB的增量。

这种项目，你让DBA去人工对账，那是不可能的。每天几百GB的增量，你怎么对？

他们用的就是KFS。在并行同步阶段，利用多通道和行哈希，把原来需要跑十几个小时的增量回放，压缩到了几个小时。追平了源端的变更。

接着他们开启了KFS的在线一致性校验。因为是政务数据，准确性要求极高。他们在白天业务高峰期开启校验，监控显示源端Oracle的CPU负载只增加了不到2%。完全没有影响到前台业务的办理。

在试运行的一个月里，校验模块陆陆续续抓到了几次数据不一致的情况。有的是因为网络瞬断导致的大事务部分失败，有的是因为某个存储过程里特殊的写法导致的解析异常。每次抓到，KFS都自动生成了修复语句并且执行了。全程运维人员只是收到了告警短信，去后台看了一下日志确认。根本不需要半夜爬起来去查数据改数据。

5.2 从手忙脚乱到无人值守的转变

你对比一下以前的做法。以前做割接，往往是一个周末，所有相关人员都在机房待命。全量同步完后，要跑脚本比对面。发现不一致，手动导出修改再导入。搞到周一天亮都弄不完。

现在有了这种全周期校验和自动修复的能力。你其实可以把更多精力放在应用层的兼容性测试上。底层数据的同步和一致性，交给工具去闭环处理。这其实才是“数据无忧”这四个字真正的含义。不是说我保证绝对不出错，而是说出了错我能自己发现、自己修，不需要人去兜底。

六、总结几句掏心窝子的话

其实做异构数据同步，大家手里可能都有几把刷子。能把数据搬过去的工具一大把。但是能把数据搬得快，同时还能在搬的过程中边搬边查、查错了还能自己改的，这就很少见了。

KFS在底层的那些优化，什么批量提交、小事务合并、各种路由策略，看起来很琐碎。但恰恰是这些琐碎的细节，把目标端的写入性能逼到了极限。这才有了在线校验的资本。

而它那个全周期数据一致性校验和自动修复，才是真正打动企业层级里那些保守的客户的关键点。因为对他们来说，慢一点还能忍，数据错了那是不能忍的。现在能做到业务不中断、性能不损耗、还能无人值守地保证一致，这套组合拳打下来，确实解决了一个行业里的大痛点。以后再遇到那种要求苛刻的同步项目，心里总算是有底了。