canal监听不到mysql变化_数据异构之 Canal 初探（技巧篇）

源码分析 Canal 系列开始了，一个全新的系列，即能探讨 canal 本身的实现原理，也是笔者源码阅读技巧的展示。

1、应用场景

提到 Canal，大家应该都能想到这是一个用于解析 MySQL binlog 日志的工具，并将 MySQL 数据库中数据同步到其他存储介质中，例如 Elasticsearch。

即 Canal 一个非常常用的使用场景：数据异构，一种更高级别的数据读写分离架构设计方法。

随着业务不断的发展，企业发展到一定阶段，发现单体的关系型数据库已无法支撑业务高速发展带来数据不断累积的压力，从而会诞生出一种设计架构：分库分表。分库分表对缓解单库数据库压力确实是一种非常好的解决方案，但又衍生出另外一种困境，关联查询不友好，甚至跨库JOIN就更加如此。

举例说明如下： 例如一个订单系统，通常有两类用户需要去查询订单，一类是顾客，一类是商家，在对数据库进行分库分表时，如果以顾客(buy_id)进行分库的话，同一个商家的订单数据会分布在不同的库中，如果以商家(shop_id)进行分库的话，同一个用户购买的所有订单数据将会分布子啊不同的库中，这样进行关联查询，就必然需要跨库进行join，其成本都会偏高。而且上面的场景只能满足一方的需求，那如何是好呢？

Canal 这个时候就闪亮登场了，在电商设计中，其实商家、顾客会被拆分成两个不同的服务，我们可以为两个不同的服务搭建不同的数据库集群，我们可以用户订单库、商家订单库进行分库，以用户订单库为主库，当用户在订单系统下单后，数据进入到用户订单库中，然后可以通过 canal 监听数据库的binlog日志，然后将数据再同步到商家订单库，而用户订单库以用户ID为维度进行分库，商家订单库以商家ID做分库，完美解决问题。

2、架构设计原理

在了解到 Canal 的基本使用场景后，我们通过 canal 官方文档，去探究一下其核心架构设计理念，以此打开进入 Canal 的神秘世界中。

首先我们简单看一下 MySQL 的主从同步原理：

从上面的图中可以看成主从复制主要分成三个步骤：

• master将改变记录到二进制日志(binary log ) 中( 这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看)
• slave将master的binary log events拷贝到它的中继日志(relay log)
• slave重做中继日志中的事件，将改变反映它自己的数据。

基于 MySQL 这种数据同步机制，那 Canal 的设计目标主要就是实现数据的同步，即数据的复制，从上面的图自然而然的想到了如下的设计：

原理相对比较简单：

• canal 模拟 mysql slave 的交互协议，伪装自己为 mysql slave，向 mysql master 发送 dump 协议
• mysql master 收到 dump 请求，开始推送 binary log 给 slave (canal)
• canal解析 binary log 对象(原始为byte流)

接下来我们来看一下 Canale 的整体组成部分：

说明：

• server代表一个canal运行实例，