Canal+RabbitMQ实现MySQL数据增量同步

最新推荐文章于 2026-01-16 17:43:22 发布

原创

最新推荐文章于 2026-01-16 17:43:22 发布 · 1.9k 阅读

标签

#java #后端 #rabbitmq #数据库

配置shardingsphere-jdbc-dev.yml

具体实现

技术栈介绍

Canal简介

canal，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。

从官方介绍就能看出，canal主要就是用来解决增量日志，增量数据订阅和消费的工具

Canal可与很多数据源进行对接，将数据由MySQL同步到ES、MQ、DB等各个数据源。

Canal的意思是水道/管道/沟渠，它相当于一个数据管道，通过解析MySQL的binlog日志完成数据同步工作。

工作原理：想要理解Canal的工作原理就需要先了解MySQL主从数据同步的原理：

MySQL主从集群由MySQL主服务器(master)和MySQL从服务器(slave)组成，MySQL主从数据同步是一种数据库复制技术，进行写数据会先向主服务器写，写成功后将数据同步到从服务器，流程如下：

1、主服务器将所有写操作（INSERT、UPDATE、DELETE）以二进制日志（binlog）的形式记录下来。

2、从服务器连接到主服务器，发送dump 协议,请求获取主服务器上的binlog日志。

MySQL的dump协议是MySQL复制协议中的一部分。

3、MySQL master 收到 dump 请求，开始推送 binary log 给 slave

4、从服务器解析日志，根据日志内容更新从服务器的数据库，完成从服务器的数据保持与主服务器同步。

根据MySQL主从同步的原理，不难看出Canal在整个过程中充当的是一个冒牌Slave的角色，流程如下：

1、Canal模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议

2、MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )。一旦连接建立成功，Canal会一直等待并监听来自MySQL主服务器的binlog事件流，当有新的数据库变更发生时MySQL master主服务器发送binlog事件流给Canal。

3、Canal会及时接收并解析这些变更事件并解析 binary log

通过以上流程可知Canal和MySQL master主服务器之间建立了长连接。

RabbitMQ

RabbitMQ 是一个开源的消息队列中间件，基于 AMQP（高级消息队列协议）实现。它支持多种消息传递模式，如点对点、发布 - 订阅等，具有高可用性、可扩展性和可靠性等特点。

RabbitMQ 的特点

高可用性：RabbitMQ 支持集群模式，可以通过多个节点组成一个高可用的集群，当某个节点出现故障时，其他节点可以接管其工作，从而保证系统的可用性。
可扩展性：RabbitMQ 支持水平扩展，可以通过增加节点的方式提高系统的处理能力和吞吐量。
可靠性：RabbitMQ 提供了消息持久化、消息确认机制等可靠性机制，可以保证消息不会丢失。
灵活性：RabbitMQ 支持多种消息传递模式，如点对点、发布 - 订阅、请求 - 响应等，可以根据不同的应用场景选择合适的消息传递模式。

关于MQ技术方案，后续文档会详细给出

分库分表

场景分析

随着订单数据的增加，当MySQL单表存储数据达到一定量时其存储及查询性能会下降，在阿里的《Java 开发手册》中提到MySQL单表行数超过 500 万行或者单表容量超过 2GB时建议进行分库分表，分库分表可以简单理解为原来一个表存储数据现在改为通过多个数据库及多个表去存储，这就相当于原来一台服务器提供服务现在改成多台服务器组成集群共同提供服务，从而增加了服务能力。

这里说的500万行或单表容量超过 2GB并不是定律，只是根据生产经验而言，为什么MySQL单表当达到一定数量时性能会下降呢？我们知道为了提高表的查询性能会增加索引，MySQL在使用索引时会将索引加入内存，如果数据量非常大内存肯定装不下，此时就会从磁盘去查询索引就会产生很多的磁盘IO，从而影响性能，这些和表的设计及服务器的硬件配置都有关，所以如果当表的数据量达到一定程度并且还在不断的增加就需要考虑进行分库分表了。

分库分表

这里举一个例子来说明什么是分库分表

例如给定一个电商系统的数据库，涉及了店铺、商品的相关业务

随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，如何进行优化呢？

我们可以把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的，如下图：将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库拆分的方法来解决数据库的性能问题

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的

分库分表四种方式

分库分表包括分库和分表两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式。

垂直分表

垂直分表是将一个表按照字段分成多表，每个表存储其中一部分字段，比如按冷热字段进行拆分

以商品信息为例，用户在选择商品界面，希望看到的是商品的名称、规格、价格等重要信息，相比之下，商品的具体描述便成为不太重要的信息了，而用户只有在对某商品感兴趣时才会查看该商品的详细描述。这些相对来说字段访问频次较低的商品信息的字段占用存储空间较大，访问单个数据IO时间较长，而商品名称、图片、价格等信息的访问频次较高。

因此根据两种数据的特性不同，就可以考虑将商品信息表拆分：将访问频次低的商品描述信息单独存放在一张表中，访问频次高的商品基本信息单独放在另一张表中