1. 课程导学与前置准备：Debezium是什么？Binlog是什么？为什么需要整合？

各位同学好，我是这门课的主讲。在数据架构这个领域摸爬滚打了十几年，说实话，最让我头疼的从来不是业务逻辑怎么写，而是数据怎么在系统之间高效、可靠地流动。

我记得2018年做一个电商中台项目，订单库是MySQL，搜索用Elasticsearch，缓存用Redis，还得同步到数仓做分析。当时团队用了定时任务扫表，结果呢？延迟高、压力大、数据还经常对不上。那段时间我几乎天天被运营同事追着问：“为什么订单状态变了，前台搜不到？”

嗯，这就是我们今天要聊的痛点。而Debezium + Binlog，就是解决这类问题的利器。

Debezium是什么？

说白了，Debezium是一个CDC（Change Data Capture，变更数据捕获）平台。它基于Kafka Connect运行，能实时监听数据库的变更事件，然后把这些事件以流的形式推送给下游系统。

我个人习惯把它理解成一个“数据库的日志订阅器”。你只要告诉它“我要监听哪张表”，它就能自动捕获这张表上的插入、更新、删除操作，并且把每次变更前后的数据都包装成一条结构化消息，发到Kafka里。

Binlog是什么？

Binlog，全称 Binary Log，是 MySQL 的二进制日志。它记录了所有对数据库执行写操作的 SQL 语句或行级变更。

你可以把它想象成 MySQL 的“黑匣子”。每一次数据修改，MySQL 都会先写 Binlog，然后再提交事务。所以 Binlog 里保存了数据库的完整变更历史。

Binlog 有三种格式：

格式	说明	特点
STATEMENT	记录原始 SQL 语句	日志量小，但某些函数（如 NOW()）会导致主从不一致
ROW	记录每一行数据变更前后的值	日志量大，但最精确，Debezium 必须用此格式
MIXED	混合模式，默认用 STATEMENT，必要时自动切换为 ROW	折中方案，但不推荐用于 CDC 场景

为什么需要整合？

你想想看，传统的同步方式无非两种：

• 定时任务扫表：每隔几分钟查一次表，比对时间戳或状态字段。缺点很明显——延迟高、对数据库有额外压力、无法捕获删除操作。
• 双写：业务代码里同时写 MySQL 和 Redis/ES。缺点更致命——代码耦合、事务不一致、维护成本高。

而 Debezium + Binlog 的整合，提供了一种非侵入式、实时、可靠的解决方案：

1. 非侵入：不需要改业务代码，不需要加字段，不需要双写。
2. 实时：Binlog 是流式的，Debezium 消费 Binlog 的延迟通常在毫秒级。
3. 可靠：Debezium 基于 Kafka，支持断点续传。即使宕机重启，也能从上次中断的位置继续消费。

我在项目中遇到过最典型的场景是：订单系统需要把数据实时同步到 Elasticsearch 做搜索。用 Debezium 监听订单表，每次订单状态变更，ES 里的文档自动更新。运营同事再也没来找过我麻烦。

课程目标与学习路径

这门课一共30章，目标是让你从零到一掌握 Debezium + Binlog 的生产级实践。不是讲概念，而是能真正落地。

学习路径分为四个阶段：

• 基础篇（第1-8章）：理解 Binlog 原理、Debezium 架构、Kafka Connect 基础。你会亲手搭建一个最小可用的 CDC 环境。
• 进阶篇（第9-16章）：深入 Debezium 的配置项、快照机制、Schema 变更处理、错误处理与重试策略。
• 实战篇（第17-24章）：对接 Elasticsearch、Redis、数仓（Hive/ClickHouse），处理大表、分库分表、数据一致性校验等真实场景。
• 运维篇（第25-30章）：监控告警、性能调优、高可用部署、版本升级、故障排查。

下面这张图，帮你快速建立本章的知识体系：