返回

利用 MySQL 的 Binlog 实现数据同步与订阅(上):基础篇

AI 摘要
博主在周末闲暇之余撰写了一篇关于大数据时代内容管理系统同质化问题的博客,并提出了通过 Binlog 实现数据同步和订阅的解决方案。文章首先解释了 Binlog 的基本概念,即 MySQL 中的二进制日志文件,主要为数据库的主从复制和增量恢复服务。接着,介绍了 Binlog 的三种模式:Statement、Row 和 Mixed,并讨论了如何开启和配置 Binlog。文章进一步阐述了 Binlog 的用途,包括实现数据库审计和事件驱动,以及业界主流的 Binlog 处理方案,如 Canal、Maxwell 和 Python-Mysql-Replication。最后,博主分享了自己的构想,计划使用 RabbitMQ、.NET Core 和 Python技术栈来实现一个基于 Binlog 的事件驱动系统。整篇文章旨在探索如何摆脱重复性工作,实现系统间数据的高效流通和整合。

终于等到了周末,在经历了一周的忙碌后,终于可以利用空闲写篇博客。其实,博主有一点困惑,困惑于这个世界早已“堆积”起人类难以想象的“大”数据,而我们又好像执着于去“造”一个又一个“差不多”的“内容管理系统”,从前我们说互联网的精神是开放和分享,可不知从什么时候起,我们亲手打造了一个又一个的“信息孤岛”。而为了打通这些“关节”,就不得不去造一张巨大无比的蜘蛛网,你说这就是互联网的本质,对此我表示无法反驳。我更关心的是这其中最脆弱的部分,即:一条数据怎么从 A 系统流转到 B 系统。可能你会想到API或者ETL这样的关键词,而我今天想说的关键词则是Binlog。假如你经常需要让数据近乎实时地在两个系统间流转,那么你应该停下来听我——一个不甘心整天写CRUD换取996福报的程序员,讲讲如何通过Binlog实现数据同步和订阅的故事。

什么是 Binlog

首先,来回答第一个问题,什么是 Binlog?Binlog 即 Binary Log,是 MySQL 中的一种二进制日志文件。它可以记录MySQL内部对数据库的所有修改,故,设计 Binlog 最主要的目的是满足数据库主从复制和增量恢复的需要。对于主从复制,想必大家都耳熟能详呢,因为但凡提及数据库性能优化,大家首先想到的所谓的“读写分离”,而无论是物理层面的一主多从,还是架构层面的CQRS,这背后最大的功臣当属主从复制,而实现主从复制的更底层原因,则要从 Binlog 说起。而对于数据库恢复,身为互联网从业者,对于像“rm -f”“删库”“跑路”这些梗,更是喜闻乐见,比如像今年的绿盟删库事件,在数据被删除以后,工程师花了好几天时间去抢救数据,这其中就用到了 Binlog。

可能大家会好奇,为什么 Binlog 可以做到这些事情。其实,从 Binlog 的三种模式上,我们就可以窥其一二,它们分别是:StatementRowMixed,其中Statement模式记录的是所有数据库操作对应的 SQL 语句,如 INSERT、UPDATE 、DELETE 等 DML 语句,CREATE 、DROP 、ALTER 等 DDL,所以,从理论上讲,只要按顺序执行这些 SQL 语句,就可以实现不同数据库间的数据复制。而Row模式更关心每一行的变更,这种在实际应用中会更普遍一点,因为有时候更关心数据的变化情况,例如一个订单被创建出来,司机通过 App 接收了某个运输任务等。而Mixed模式可以认为是Statement模式和Row模式的混合体,因为Statement模式和Row模式都有各自的不足,前者可能会导致数据不一致,而后者则会占用大量的存储空间。在实际使用中,我们往往会借助各种各样的工具,譬如官方自带的mysqlbinlog、支持 Binlog 解析的StreamSets等等。

好了,下面我们简单介绍下 Binlog 相关的知识点。在使用 Binlog 前,首先需要确认是否开启了 Binlog,此时,我们可以使用下面的命令:

SHOW VARIABLES LIKE 'LOG_BIN'

如果可以看到下面的结果,则表示 Binlog 功能已开启。

Binlog已开启示意图
Binlog已开启示意图
如果 Binlog 没有开启怎么办呢?此时,就需要我们手动来开启,为此我们需要修改 MySQL 的my.conf文件,通常情况下,该文件位于/etc/my.cnf路径,在[mysqld]下写入如下内容:

# 设置Binlog存储目录
log_bin                      =    /var/lib/mysql/bin-log
# 设置Binlog索引存储目录
log_bin_index              =    /var/lib/mysql/mysql-bin.index
# 删除7天前的Binlog
expire_logs_days          = 7
# 集群内MySQL服务器的ID
server_id                 = 0002
# 设置Binlog日志模式
binlog_format              = ROW

除此之外,我们还可以设置下面这些选项:

# 设置Binlog文件最大的大小
max_binlog_size
# 设置当前多少个事务缓存在内存中
binlog_cache_size
# 设置当前多少个事务暂存在磁盘上
binlog_cache_disk_use
# 设置最大有多少个事务缓存在内存中
max_binlog_cache_size
# 设置选取或者忽略的数据库
binlog_do_db/binlog_ingore_db

设置完以后,通过下面的命令重启 MySQL 即可:

service mysql restart

或者

service mysqld restart

通常,我们可以通过下面的命令来获取 Binlog 的当前状态,请注意,该命令必须要在主库上执行

SHOW MASTER STATUS

此时,我们会得到下面的结果:

查看Binlog状态
查看Binlog状态
这里可以得到三个重要的信息,即从日志文件mysql-bin.000388的特定位置135586062开始,可以获得一组新的日志信息,而这些日志信息都是来自数据库实例b1328d03-0b5c-11ea-8ee8-005056a1616f:1-27768340。有了这三个信息以后,我们就可以去查看对应的 BinLog,此时,我们需要使用到下面的命令:

SHOW BINLOG EVENTS IN 'MYSQL-BIN.000388' FROM 135586062

此时,ROW 模式下的 Binlog 如下图所示:

ROW模式下的Binlog
ROW模式下的Binlog
可以注意到,这些 Binlog 由不同的事件构成。如果你是在 MySQL 终端下输入命令,那么,你还可以使用官方自带的工具mysqlbinlog,博主这里使用的开源的数据库工具DBeaver,如果你经常需要和不同的数据库打交道,而又不想每一种数据库都去安装一个客户端的话,我认为这是一个非常不错的选择。关于 Binlog 的使用我们就先暂时说到这里,因为还有更重要的事情要做。

Binlog 有什么用

实现数据库审计

你可能觉得我明知故问,你刚刚不是说 Binlog 主要用来做主从复制和增量恢复吗?自然,这是 Binlog 在设计之初的主要用途。可我们都知道,事物有时候并不会想着我们期待的方向发展,譬如原子弹成为战争机器、社交软件成为“约炮神器”、共享单车成为“城市垃圾”等等。还记得博主曾经写过一篇关于数据库审计的[博客](https://blog.yuanpei.me/posts/1289244227/吗?当时,我们是重写了 EF/EF Core 中 DbContext 的 SaveChanges()方法,并借助 ChangeTracker 对获取实体修改前后的值。其实,从现在的角度来看,我们有更好的选择,毫无疑问,Row 模式下的 Binlog 本身就是天然的数据库审计,每一行数据变化前后的情况,我们都可以获得,并且可以区分出它是 Insert ,还是 Update,还是 Delete,所以,Binlog 的第一个用途就是可以用来做数据库审计,因为它发生在数据库层,从某种意义上来讲,消解了 EF 和 Dapper 这种 ORM 间的差异。

实现事件驱动

其次,我们在实际业务中,常常需要用到"领域事件“这个概念,即使项目并没有采用**领域驱动设计(DDD)**的思想,即使项目中并没有采用”事件驱动“的业务模式,可事实就是,总有人关心着数据的产生和变更,而能提供给第三方系统订阅自己感兴趣的事件的能力,无疑要比开发一个又一个大同小异的同步接口要好得多,推(Push)模式在大多数情况下要比拉(Pull)模式要好,为什么呢?因为数据传输的压力更小,更能满足数据实时性的要求。然而,由于没有按照领域模型去设计业务,导致事件代码与业务代码耦合非常严重,基于 Binlog 的事件分发机制显然有更好的普适性。以博主最近处理的业务为例,A 系统中的司机、设备、用户在新建/更新更新时,需要把新数据推送到 B 系统,因为这类纯数据类的"变化"没有实际业务意义,所以,人们不舍得为这些变化去分发事件,而要想分发事件,又不得不去面对强耦合带来的阵痛,所以,Binlog 的第二个用途是可以作为事件源来实现事件驱动。

业内主流方案

如果你觉得通过第一节的内容,可以非常容易地实现 Binlog 的解析,那么,我觉得你并没有想清楚 Binlog 处理过程中的难点在哪里?首先,每次读取 Binlog,必须要知道对应的日志文件和位置,而如果在新的 Binlog 产生前,没有处理完原来的 Binlog,就必须要记录对应的日志文件和位置,而且经过博主本人测试,Binlog 无法直接给查询语句追加过滤条件,来达到筛选某些数据库、表以及事件的目的,而且日志文件的格式会因为模式的不同而不同,最主要的一点是,直接在主库上读取 Binlog 会给数据库带来访问压力,所以,主流的方案,是让客户端伪装成“从库”,关于一点,我们可以配合下面的图片来理解。

MySQL主从复制原理
MySQL主从复制原理
可以注意到,完成主从复制需要一个 Relaylog + 两个线程,即,主库产生的 Binlog,首先由从库的 I/O 线程进行读取,这一步会产生 Relaylog,顾名思义,这是一个处在中间状态的中继日志,而中继日志最终会交由从库的 SQL 线程来处理,所以,这是从库执行 SQL 语句的阶段,整个过程是异步化的操作,所以,不会对主库产生太大的压力。如果我们直接读取主库的 Binlog,实际上是把所有压力都转移到主库,不仅需要负责“读”,还需要复杂“写”。主流的方案,目前比较推荐的是阿里的Canal、Zendesk 的Maxwell、以及来自社区的Python-Mysql-Replication,下面是一个简单的对比,方便大家做技术选型。

CancalMaxwellPython-Mysql-Rplication
开源方阿里巴巴Zendesk社区
开发语言JavaJavaPython
活跃度活跃活跃活跃
高可用支持支持不支持
客户端Java/Go/PHP/Python/RustPython
消息落地Kafka/RocketMQ 等Kafka/RabbitNQ/Redis 等自定义
消息格式自定义JSON自定义
文档详略详细详细详细
Boostrap不支持支持不支持

说说我的构想

众所知周,我是一个有一点“懒惰”的人,考虑到前面两种方案都比较重,即使通过 Docker 来安装。对我来说,这是一个验证想法的过程,所以,我选择的搭配是 RabbitMQ + .NET Core + Python 的方案,因为 Kafka 需要 ZooKeeper,而在验证想法的阶段,自然是越简单越好。我正打算参考微软的 eShopOnContainers 的项目, 实现一个消息总线(EventBus),恰好这个项目中使用了 RabbitMQ,而且从某种意义上来说,RabbitMQ 更接近传统意义上的消息队列,它提供的重试、确认、死信等这些机制都比较完善,可以让我把精力集中在快速实现上,毕竟你看到这些博客,都是我挤出时间来完成的。选择 Python 就更直接了,因为安装、运行都非常容易,或许 Kafka 的吞吐性能更好,但我觉得掌握核心思想才是最重要的吧!

总而言之,在这里,我选择了自己最熟悉的技术栈。整体思路是,首先,.NET Core + RabbitMQ 实现一个消息总线,并对外提供发布事件的 API 接口。其次,利用 Python-Mysql-Replication 实现一个读取 Binlog 的后台程序,这些 Binlog 最终会以 JSON 的形式发布到 RabbitMQ 上。最后,实现针对特定事件的 IEventHandler接口,消息总线会自动调用这些 Handler 去处理消息。至此,就实现了针对 Binlog 的订阅和消费。众所周知,消息总线的一大优点就是解耦,我们就可以摆脱以往定时轮询 + 打标记(Flag)的宿命轮回,只需要编写对应的 Handler 即可,其实我觉得这是一种思维上的转变,就是"主动"到"被动"的转变,并不是说我们帮客户做得越多越好,而是我们能让客户意识到它可以做哪些事情。同样的,我绘制了一个简单的流程图来作为说明:

基于RabbitMQ的EventBus实现
基于RabbitMQ的EventBus实现

本文小结

其实,重复的工作做久了都会感到厌烦的,所以,真正让你摆脱“体力劳动”的只能是换一种高度来看问题。这几年做 2B 业务下来,最大的体会是企业级软件最难的是,如何在各种种类繁多的软件,譬如 OA 、金蝶、用友、SAP 、ERP 、CRM 等中做好一个“配角”,数据如果无法在这张网络中流通,则永远都是一潭死水,而如果要打通各个系统间的数据,则免不了写一个又一个的同步接口。这篇博客以 MySQL 的 Binlog 为切入点,试图通过 Binlog 来实现特定业务的“事件驱动”。Binlog 是实现主从复制的重要机制,而基于这一机制,业界普遍的做法是利用 MySQL 的交换协议,让客户端"伪装"成一个从库,在比较了 Canal 、Maxwell 以及 Python-Mysql-Replication 后,博主选择了. NET Core + RabbitMQ + Python 的方案,目标是让 Binlog 可以发布到消息总线(EventBus)中供消费者订阅和消费。在下一篇博客中,我们讲介绍基于 RabbitMQ 实现一个消息总线(EventBus)的相关细节,欢迎大家继续关注我的博客,今天这篇博客就先写到这里,大家晚安!

Built with Hugo v0.126.1
Theme Stack designed by Jimmy
已创作 274 篇文章,共计 1038172 字