数据库实时同步与异步同步：机制、原理与工程实践-平芜编程栈

数据库的实时同步，说穿了就是一个“追上另一个库的每一次变化”的活儿。我刚入行那会儿，最头疼的就是主库一挂、从库数据和主库差了十万八千里，恢复业务全靠手工补数，补到天亮是常有的事。后来接触的同步方案多了，才慢慢搞明白实时同步和异步同步根本不是“快和慢”的关系，而是两种完全不同的工程取舍。这篇东西，我按自己的理解把这两套机制、底层原理、实操方案和踩过的坑一次性讲透。

不管是刚做数据库课程设计的学生，还是在维护Oracle、达梦、MySQL、ClickHouse的生产老手，只要你被“数据怎么搬过去、怎么保持一致”这个问题折磨过，这篇文章应该都能给你一些参考。我会先把同步机制拆开看，再给出一套从MySQL同步到ClickHouse的可落地配置，最后把我们上线时遇见的典型故障和排查思路一并整理出来。

1. 同步机制全景：实时同步和异步同步到底在同步什么

1.1 实时同步不是“快一点的异步”

很多人对实时同步有个误解，以为它就是把同步频率调高、定时任务加快，本质上还是隔一会儿跑一次。这里必须先纠偏：实时同步和异步同步的区别不在速度，而在“触发方式”。

实时同步的核心是事件驱动（Event-Driven）。源库的每一条增删改操作都会产生一个事件，比如MySQL里的binlog、PostgreSQL里的WAL、Oracle里的Redo Log，同步组件监听并解析这些事件，一旦有新的变更就立刻将其投递到目标端执行。源库提交事务的瞬间，目标库基本上也在毫秒级之内完成了同样的变更，整个过程不需要人工干预，也不需要定时轮询。

异步同步的核心则是批处理驱动（Batch-Driven）。它的流程通常是定一个间隔，比如每5分钟、每小时跑一次任务，把源库里旧的数据批量读取出来，经过清洗转换后写入目标库。这里有个关键点：异步同步拿到的往往是“某个时间点的快照”，而不是“连续变化的日志流”。快照与快照之间新产生的数据，只能在下一个周期再次被扫描带走，这就天然导致目标库的数据滞后于源库。

我自己的理解是这样的：实时同步解决的是“丝滑一致”的问题，异步同步解决的是“批量搬运”的问题。前者像一根水管直接接通两个水池，水流几乎同时涌动；后者像用桶一桶一桶地拎水，虽然每次量很大，但中间总有时间差。

1.2 异步同步的价值不在“慢”，而在“稳”

既然异步同步有延迟，为什么那么多系统还在用？因为它在某些场景里反而比实时同步更合适。

第一，异步同步对源库的侵入性极低。大多数异步方案只是定期执行SELECT查询，只要SQL写得合理，走的是索引，基本不会对源库造成持续的额外压力。实时同步如果配置不当，比如binlog解析线程过多、目标端消费过慢，反而可能把源库的IO拖垮。

第二，异步同步天然适合数据仓库和报表类场景。数仓里的分析任务本来就不需要看到秒级的数据，它是按天、按小时做数据切片和指标汇总的。如果为了这种场景强行上实时同步，不仅成本高，还会产生大量无意义的中间数据。

第三，异步同步可以很方便地做数据校验和历史归档。因为它是批量读取，所以可以顺带在同步过程中做去重、格式转换、分区切换，甚至可以把历史数据从一个存储迁移到另一个存储，而实时同步一般来说只会关注增量变更，做这种历史数据的批量处理反而不擅长。

所以，一个成熟的数据库同步体系，往往是实时和异步共存的。实时链路保证业务核心数据的低延迟可见，异步链路用来做全量初始化、离线分析、日终对账。两者不是替代关系，而是分工关系。

2. 核心原理拆解：binlog、CDC、消息队列和最终一致性

2.1 binlog是MySQL同步的“第一桶金”

做MySQL实时同步，不管用什么工具，底层几乎都绕不开binlog。你要理解实时同步，先得理解binlog里到底装了什么。

MySQL有几种binlog格式，最常用的是ROW、STATEMENT、MIXED三兄弟。实时同步场景下，我强烈建议使用ROW格式，因为ROW格式记录的是每一行数据变更前后的完整镜像。比如执行一条UPDATE user SET age = 30 WHERE id = 100，STATEMENT格式可能只记了一条SQL语句，比较精简，但同步到目标端重放时，如果目标端的数据和源库有微小差异，结果就不一样了。ROW格式则直接把id=100这一行更新前后的值写清楚，目标端只需按图索骥地改行，准确率最高。

可以这样类比：STATEMENT格式相当于给你一份“菜谱”，告诉你“把这道菜再加热一下”，但每个厨房的锅和火候不同，做出来的味道可能不一样；ROW格式相当于直接给你“做好的菜”，你只需要把它端上桌。

在配置MySQL时，至少要开启这几项：

[mysqld] server-id = 1001 log-bin = mysql-bin binlog_format = ROW expire_logs_days = 7 max_binlog_size = 256M

server-id必须设置为唯一值，这个在搭建主从和配置同步工具时是硬性要求，同一套复制链路里不允许出现两个相同的server-id，否则MySQL会认为发生了复制环路。binlog_format = ROW是我们做实时同步的基础，expire_logs_days则控制binlog保留天数，太短会导致同步组件断连后日志被清掉，没法重新拉取；太长又占磁盘空间，我们生产环境一般根据同步延迟情况留3到7天。

2.2 实时同步的三种主流姿势：触发器、CDC、业务双写

实时同步不是只有一种实现方式，我梳理下来大致有三类：

姿势一：触发器（Trigger）方案。在源库的表上建立触发器，每有INSERT、UPDATE、DELETE就写入一张中间日志表，再由同步程序把中间表的变化读出来，投递到目标端。这种方案实现简单，开发成本低，但本身对源库的事务性能有较大冲击，因为触发器是在原事务内部同步执行的，属于额外负担。而且一条SQL语句即使只影响一行，也要触发多个触发器的动作，在高并发写入场景下很容易拖慢业务。个人建议：中小系统、数据量可控、表结构不常动的场景可以试试；高并发生产环境尽量别碰。

姿势二：CDC（Change Data Capture）方案。CDC的核心思想是“捕获数据变更”，它不依赖触发器，也不需要在业务代码里额外开发，而是直接读取数据库的事务日志。MySQL的binlog、PostgreSQL的逻辑复制槽、Oracle的LogMiner和GoldenGate都属于这一类。以开源工具Canal为例，它会伪装成一个MySQL从库，向主库请求binlog，然后解析成结构化的事件数据，再投递给下游消费者。这个方案对源库影响相对小，实时性也高，是我们生产环境首选。

姿势三：业务双写方案。也就是在应用代码层面，写完主库后再同步写一份到目标库或者消息队列。这个方案的优点是可控性强，可以在业务代码里做事务补偿；缺点是对代码侵入性极大，而且一旦漏写某条数据，很难靠事后机制补齐。双写方案一般只在系统规模较小、同步逻辑完全由自己掌握时才推荐，否则维护成本会越来越高。

2.3 异步同步的消息中间件与批量落库

异步同步不止是定时跑个任务，它还可以和消息队列深度绑定。举个例子：业务系统每次写入主库后，顺手往Kafka或RocketMQ里发一条消息，异步消费端从消息队列里拿到这批变更，再批量写入目标库。这里的“异步”是指业务请求和同步结果的解耦——业务方不需要等待目标库写入完成就可以返回。

不过，消息队列方案里有个很容易忽略的坑：业务方发消息的动作和写数据库的动作不是一个本地事务。如果先写库后发消息，消息发出后目标库写入失败，就会产生“源库有、目标库无”的不一致；如果先发消息后写库，业务方一旦回滚，消息却已经发出去了，产生“目标库多了一条数据”的脏数据。

我们现在的处理方式是：业务写入主库后，把消息以“本地消息表”的方式先存在同一个数据库事务里，再由一个异步线程扫描本地消息表，确认消息发送成功后更新状态。目标端消费消息时，必须保证消费逻辑的幂等性，否则重复投递一样会产生脏数据。

纯异步批处理则是更朴素的方案：每天凌晨跑一个定时任务，用SELECT ... WHERE update_time >= ?的方式把增量数据捞出来，然后批量写入目标库。这种方案对实时性要求不高的场景完全够用，而且排查问题最方便，因为每一批数据都是确定性的。

3. 实操连线：一套MySQL到ClickHouse的实时同步方案

3.1 为什么选ClickHouse作为同步目标，环境怎么准备

这两年ClickHouse在分析场景里特别火，很多团队的业务库还是MySQL，但分析报表用的是ClickHouse，MySQL到ClickHouse的数据同步就成了刚需。ClickHouse的MergeTree引擎本质上是为批量写入和列式分析设计的，它在单条实时写入上百亿行这种场景下并不擅长，所以如果把ClickHouse当作OLTP库高强度写，很容易触碰到它的短板。

我的建议是：实时同步过来的数据先写到Kafka，再由ClickHouse的Kafka引擎表消费并批量落盘，让ClickHouse用自己最舒服的批量合并方式去处理数据。这也是为什么我在第一节强调“实时”不代表“每条都立刻写入”，你完全可以做一个“秒级采集、分钟级落库”的准实时方案。

环境准备分三块：一台MySQL（比如5.7或8.0），保证开启binlog；一套Kafka（或直接用Canal自带的适配器直接写ClickHouse）；一套ClickHouse（21.8以上版本）。如果你的ClickHouse开启了集群模式，需要注意副本表和分布式表的配置，同步目标最好指向分布式表，避免数据分片不均匀。

3.2 Canal的配置与事件订阅：监听binlog的正确姿势

Canal是阿里巴巴开源的一套MySQL binlog解析工具，也是目前Java生态里用得最广的CDC方案之一。我用它做过很多次同步，稳定性和文档成熟度都有保证。

Canal的使用分三步：

第一步，在MySQL里创建专用的同步账号，并授予复制权限：

CREATE USER 'canal'@'%' IDENTIFIED BY 'canal_pass'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; FLUSH PRIVILEGES;

这里必须提醒：只给SELECT和复制权限就够了，绝对不要给这个账号分配删除或修改业务数据的权限。同步账号越权，一旦被误操作就是灾难。

第二步，下载Canal并修改conf/example/instance.properties：

canal.instance.master.address = 127.0.0.1:3306 canal.instance.dbUsername = canal canal.instance.dbPassword = canal_pass canal.instance.connectionCharset = UTF-8 canal.instance.filter.regex = db_name\\..*

filter.regex是重点，你可以用它精确控制同步哪些表。比如只同步order_db下的t_order和t_order_item，可以写成db_name\\.t_order.*,db_name\\.t_order_item。如果在这块偷懒，把全部表都同步过去，后面过滤规则会更难维护。

第三步，在业务代码里对接Canal客户端，监听数据变更事件。简单写法是使用canal.client库：

CanalConnector connector = CanalConnectors.newSingleConnector( new InetSocketAddress("127.0.0.1", 11111), "example", "", ""); connector.connect(); connector.subscribe("db_name\\..*"); while (running) { Message message = connector.getWithoutAck(100); long batchId = message.getId(); if (batchId == -1 || message.getEntries().isEmpty()) { // 没有数据变更，稍等再取 Thread.sleep(200); continue; } for (CanalEntry.Entry entry : message.getEntries()) { // 解析entry，区分INSERT、UPDATE、DELETE // 投递到Kafka或直接写入目标端 } connector.ack(batchId); // 确认这条批次处理完毕 }

这个ack机制很关键，它就像快递签收单。消费端处理完这一批事件后，必须调用ack(batchId)通知Canal可以继续发送下一条；如果处理过程中异常，就不要ack，Canal端会重新投递。但这里又引出一个问题：重新投递可能导致目标端重复写入，所以你的目标端写入逻辑必须设计成幂等。

我们在生产里用的做法是：目标表里带一个sync_version字段，每次写入都带上源库binlog的坐标（日志文件名加偏移量），如果目标端发现同样的坐标已经处理过，就跳过。这样即使消费端重启、重复拉取，也不会污染数据。

3.3 异步兜底链路：定时批量任务和幂等设计

实时链路做得再漂亮，也难免有意外，比如Canal挂了、Kafka分区繁忙、目标库锁表。这时候如果只有实时链路，数据就会一直落后，恢复之后还要想办法补齐缺口。所以我强烈建议给实时同步配一条“异步兜底”链路。

异步兜底的做法不复杂：每小时跑一次定时任务，扫描源库中最近两小时有变更的记录：

SELECT id, order_no, status, update_time FROM order_db.t_order WHERE update_time >= DATE_SUB(NOW(), INTERVAL 2 HOUR) AND update_time < DATE_SUB(NOW(), INTERVAL 10 MINUTE);

这里特意把最近10分钟的数据排除掉，避免和实时链路已经完整处理过的最新数据产生竞争。每次扫描完成之后，把数据写入一个临时表，再做去重合并，最后Upsert到目标库。

异步兜底的写入操作，我们用的是ClickHouse的ReplacingMergeTree引擎。这个引擎允许你写入重复数据，但会在后台合并时根据ORDER BY字段去重。比如你用ORDER BY (id)指定去重键，那么同一id的多条记录在Merge后只会保留最新的一条（按版本字段或写入顺序）。这样的设计可以允许定时任务和实时任务偶尔写入同一条数据，最终结果也不会乱。

这个兜底链路的价值，我举一个实际场景：某次我们把Canal的内存设置调小了，结果消息堆积把Canal搞挂了，实时链路断了差不多40分钟。如果没有定时兜底任务，这40分钟的业务数据就只能靠人肉补脚本处理，而我们当时的兜底任务在Canal恢复后自动把这个缺口补上了，最终对账差异为零。

4. 故障排查实录：同步延迟、数据不一致和循环同步

4.1 同步延迟堆到几十万，怎么定位瓶颈

生产环境里最常遇到的同步问题就是“延迟”。表现是源库一条数据已经更新了，但目标库怎么查都查不到，或者目标库的监控面板显示同步位点落后源库一大截。

我的排查路径一般是这样的：

第一步，确认延迟发生在哪个环节。如果走的是MySQL到Kafka到ClickHouse的链路，你就分别看MySQL的binlog位点、Kafka的消费位点、ClickHouse的写入速率。哪个环节消费位点增长最慢，瓶颈就在哪里。

第二步，如果瓶颈在Canal，先看Canal是否频繁GC。默认JVM堆内存可能不够用，binlog解析如果赶上大事务，会产生大量对象，GC一停顿，消费位点就原地不动。我们当时把Canal的-Xms和-Xmx都调整到4G，延迟立刻从小时级降回秒级。

第三步，如果瓶颈在ClickHouse写入，多半是批量过小导致的。ClickHouse单次insert条数越大，整体吞吐越高，所以实时消费端不要一条一条地insert，而是攒够一定条数或间隔一定时间再批量写入。我们通常设置攒够5000条或每1秒刷一次，实测吞吐提升非常明显。

4.2 数据对不上账，校验和修复的办法

同步系统做得再好，对账仍然是必不可少的。我们的对账方案分两层：

第一层是数量对账。每天跑一个任务，统计源库和目标库每个表的总行数，对比差值。这个方法看似笨拙，但成本低，能发现大部分漏同步的问题。注意这里要选合适的统计字段，最好用主键ID的最大值和最小值辅助判断，否则在数据量很大的表上COUNT(*)本身就很慢。

第二层是抽样内容对账。对核心表按主键Hash抽样，抽取一定比例的数据，把源库和目标库的关键字段逐一比对。这里有个实用技巧：不要按行一条一条地拼接字符串比对，效率太低。可以按主键分组，把多个字段拼成MD5值，然后对比MD5，一旦MD5不一致再展开具体字段排查，效率能提升不少。

如果发现确实有漏同步的数据，小批量的直接跑补数SQL；大批量的就把主键范围捞出来，重新写入Kafka，让实时链路重放一遍。修复完成后一定要重新执行一次对账脚本，确认差异清零才能收工。

4.3 循环同步和死锁，是怎么把数据库拖垮的

这个坑我在早期做双向同步时踩过。所谓双向同步，就是A库和B库互相同步，这样任意一边的写入都能在另一端生效。听起来很美，但如果控制不好，A库的一条更新同步到B库之后，B库的变更日志里会再次记录这条更新，然后又被反向同步回A库。A库收到之后，又产生一条新日志，再同步到B库……如此循环，数据被无限放大，最终把两个库都拖垮。

规避方法有几种：一是用数据源标记，在同步过来的数据里写入一个特殊的源标识，消费端看到这个标识就跳过业务逻辑处理，只做数据落地；二是从日志里过滤掉同步进程自己产生的变更，比如给同步账号打标记，binlog里带有特定server-id的记录不再转发；三是不要做双向同步，改为单向同步加业务层写路由，这是最保险的方案。

另外，同步写入目标库时也容易引起死锁。比如两个事务分别同步两条互相引用的记录，加锁顺序不一致，就死锁了。解决思路有两个：一是让同步线程串行化，二是在批量写入时按主键排序，保证加锁顺序一致。我们最终选的是后者，因为吞吐更高，也不影响实时性。

5. 工具选型和场景建议：从开源到国产数据库的同步方案速查

5.1 MySQL生态的主流同步工具对比

很多人问我同步工具选哪个好，我通常会把它们分成三类来看。

第一类是数据库原生主从复制，比如MySQL的Replication、PostgreSQL的流复制。它最适合做高可用场景，主库宕机后从库可以快速提升为新的主库。但原生复制的目标库类型必须和源库一致，它解决不了异构数据库同步的问题。

第二类是CDC与消息管道工具，比如Canal、Debezium、Maxwell、Flink CDC。这类工具把数据库变更事件化，再投递到消息队列或目标端。它们能解决数据库到数仓、到搜索引擎、到缓存的异构同步问题，也是目前实时同步的主流选择。Debezium胜在开源生态好，原生支持Kafka Connect；Canal在MySQL领域更接地气，国内资料多；Flink CDC则在流计算场景下能把数据和计算引擎天然融合。

第三类是商业ETL和迁移工具，比如DataX、CloudCanal、NineData等。DataX是阿里巴巴开源的离线数据同步工具，适合大批量全量迁移；CloudCanal等商业工具则在UI可视化和全增量一体化上做得更完善，不过在选型前要评估好授权成本和平台绑定风险。

我个人的选型经验是：如果只是同构数据库之间的高可用，优先用原生复制；如果是异构实时同步，优先用Canal或Debezium加Kafka；如果是一次性全量迁移，优先用DataX；如果团队业务比较杂、希望少写代码，可以评估商业同步平台。

5.2 达梦、人大金仓等国产数据库同步怎么处理

现在不少项目都在用达梦、人大金仓等国产数据库。这类数据库同步方案没有MySQL那么统一，但也不用慌，核心思路是一样的：先看它是否提供兼容MySQL或PostgreSQL的复制协议。

达梦数据库提供DTS数据集成工具，可以完成同构和异构场景下的数据迁移与同步。如果是把MySQL增量同步到达梦，目前比较稳妥的做法是用支持异构同步的商业工具或者达梦官方工具。人大金仓KingbaseES则兼容PostgreSQL协议，很多基于PostgreSQL逻辑复制的同步工具可以直接或稍作适配后使用。

针对这类国产库，我的建议是：选型前先确认同步目标和源库的兼容性。比如源库是MySQL，目标库是达梦，你就需要确认是否有达梦的CDC插件或驱动能被Flink CDC、Canal等工具识别。如果官方没有提供适配组件，就不要强行用开源工具硬怼，否则排查问题会非常痛苦。另一个思路是用业务中间层解耦：源库的binlog事件先落到Kafka，再开发一个小型消费程序，用达梦的JDBC批量写入目标表。只要你的同步逻辑足够通用，换目标库时只需要换一个writer实现。

5.3 数据同步架构设计的三条铁律

做过多套同步架构之后，我总结出三条自己一直遵守的规则，分享给你。

第一条，实时同步必须可监控。你能随时看到当前同步位点、链路延迟、消费速率和异常事件数量。没有监控的同步链路，就像没有仪表盘的飞机，出了状况根本不知道从哪开始排查。我们是在Prometheus里暴露了Canal消费者位点和Kafka消费组Lag指标，再配上告警规则：延迟超过1分钟就通知值班人员，超过5分钟直接打电话。

第二条，同步链路必须可回放。也就是说，每次数据变更最好落到一个持久化的中间介质上，比如Kafka。这样即使目标端挂了，你也能在恢复后从Kafka重新消费，把缺漏的数据补回来。如果方案里没有这个中间介质，一旦下游故障，源库的旧binlog又过期了，数据就永久丢失了。

第三条，写入目标库必须幂等。不管同步工具宣称自己多么可靠，你都要假设它可能重复投递。目标端的写入逻辑只有做到“重复执行结果相同”，才能在上游重试、消费者重启这些意外面前保持最终一致。实现幂等的手段有主键去重、版本号比较、幂等键表等，根据目标库类型灵活选用。