江苏龙网

  1. 首页 > 人文 > >

『MySQL』Maxwell和Canal的选型和规划


这是学习笔记的第 2190篇文章
读完需要
分钟
速读仅需7分钟
关于Maxwell和Canal的选型和规划 ， 之前在团队内部也讨论过几次 ， 从功能和长期的支持 ， 定制方面 ， 似乎哪个方面都不是很好比较 ， 毕竟根据每个企业的特点 ， 都有难以取舍的痛 。
一般说要比较 ， 基本都会拿出这幅图来（数据带有主观特点 ， 仅供参考）
『MySQL』Maxwell和Canal的选型和规划
本文插图
我们在这个基础上做些补充 。
首先对于这个工具的定位 ， 我们如果是主要基于数据流转来作为虚拟从库这样一个组件 ， 其实选择Maxwell和Canal的差别会比较明显 。
Maxwell的定位基本上一句话就能说清楚 ， MySQL+Kafka ， 如果是基于MySQL和Kafka组合的技术栈 ， Maxwell无疑是一种可直接上手的工具 ， 基本不需要复杂的配置即可跑通一个demo,快速开始测试,换句话说Maxwell部署很简单 ， 上手简单 ， 跑通一个完整的测试全然没有问题 ， 对于缺乏基础建设 ， 短时间内需要快速迭代的项目和公司比较合适 。
Canal的部署相对来说要复杂许多 ， 对于开发侧的要求较高 ， 有两个值得一提的参考点 ， 一个是bootstrap,对于数据初始化来说 ， 这是一个缺失 ， 和Canal这个工具本身的定位有关 ， 第二个是数据落地 ， 得自己写客户端 ， 当然除此之外 ， 在服务高可用 ， 文档 ， 数据分区 ， 自带图形管理工具方面 ， Canal确实有自身的优势 ， 而且据说产品内部版本已经对接了商业数据库侧 。 对于大中型的项目 ， 具有团队开发优势的项目和公司来说 ， 可以考虑 ， 或者可以作为自造轮子的参考 。
这几天看了下两个开源项目相关的代码 ， 有了更进一层的认识 。 GitHub的流行度是一个风向标 ，
『MySQL』Maxwell和Canal的选型和规划
本文插图
【『MySQL』Maxwell和Canal的选型和规划】

『MySQL』Maxwell和Canal的选型和规划
本文插图
从这个流行度来看 ， 两个项目的量级确实差别挺大 ， 一方面阿里有自身的开源号召力 ， Maxwell在这个数据面前略显逊色 。
不过从代码层面来看 ， 逐步理解了这个差异 ， 首先关于MySQL协议的Java实现 ， 这个整个工具的核心部分 ， 在Canal中都是自下而上都实现了 ， 而Maxwell中翻了一圈代码 ， 竟然没有 ， 发现是在另外一个开源项目mysql-binlog-connector-java中 ， 这个项目的协议实现很精巧 ， 对于理解协议层的一些细节很有帮助 。
『MySQL』Maxwell和Canal的选型和规划
本文插图
当然从更细一层来说 ， Canal是模拟MySQL Slave ， 主动从Master端拉取日志数据 。 而mysql-binlog-connector是一个解析库 ， 它有两种模式：BinaryLogFileReader日志读取模式 ， 和BinaryLogClient客户端访问模式 ， 在实现方式上更加灵活 ， 而且BinaryLogFileReader这个部分的实现算是一个杀手级特性 ， 如果规划了binlog集市 ， 在这个基础之上简直如虎添翼 。
Maxwell还有什么细节 ， 它基于C3P0连接池 ， 所以在Slave端会看到有几个复制相关的会话 ， 在测试框架部分采用了TestNG的开源项目 ， 在数据落地部分 ， 支持的目标端非常丰富 ， Redis ， Kafka ， Kinesis ， 在数据接入层面的功能非常完善 ， 目前看没有后端的功能支持 。
Canal的实现是前后端组合 ， 还包含一个子项目是平台化管理入口 ， 它对接的后端更多是基于自身的技术栈体系 ， 把整个链路能够打通 。

『MySQL』Maxwell和Canal的选型和规划


推荐阅读


上一篇：手机之友TB■国美U9、vivoY95、华为畅享10e对比

下一篇：『科技』OPPO Reno手机上的几个小功能，你有那些还不知道