一.背景
昨日与已离职的同事JL·C讨论如何在业务逻辑中以尽可能低耦合的方式进行日志的收集与打点，其间聊到了如何使用基于BinLog的MySQL增量消息解析机制 来取代 自定义注解+AOP机制。写这篇文章用以介绍这一机制的实现机理，和对这项技术更广泛、更贴合的应用场景的思考。
业务日志收集与打点，类似于关系型数据库的 trigger（触发器），但数据库 trigger 编写困难并且维护成本搞，并且很难与其他业务系统进行结合。所以此基于BinalyLog的MySQL增量消息解析机制能够在整合业务系统并低耦合方面有较大应用场景。
二.技术栈
2.1 Canal
Canal 是阿里巴巴旗下的一款开源项目，纯 Java 开发。基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了 MySQL（也支持 mariaDB）。
2.1.1 简介
canal [kə’næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费
早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。
基于日志增量订阅和消费的业务包括
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理
当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x
2.1.2 工作原理
MySQL 主备复制原理
MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件 binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
canal 工作原理
canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)