Maxwell和Canal的选型和规划

关于Maxwell和Canal的选型和规划，之前在团队内部也讨论过几次，从功能和长期的支持，定制方面，似乎哪个方面都不是很好比较，毕竟根据每个企业的特点，都有难以取舍的痛。

一般说要比较，基本都会拿出这幅图来（数据带有主观特点，仅供参考）

我们在这个基础上做些补充。

首先对于这个工具的定位，我们如果是主要基于数据流转来作为虚拟从库这样一个组件，其实选择Maxwell和Canal的差别会比较明显。

Maxwell的定位基本上一句话就能说清楚，MySQL+Kafka，如果是基于MySQL和Kafka组合的技术栈，Maxwell无疑是一种可直接上手的工具，基本不需要复杂的配置即可跑通一个demo,快速开始测试,换句话说Maxwell部署很简单，上手简单，跑通一个完整的测试全然没有问题，对于缺乏基础建设，短时间内需要快速迭代的项目和公司比较合适。

Canal的部署相对来说要复杂许多，对于开发侧的要求较高，有两个值得一提的参考点，一个是bootstrap,对于数据初始化来说，这是一个缺失，和Canal这个工具本身的定位有关，第二个是数据落地，得自己写客户端，当然除此之外，在服务高可用，文档，数据分区，自带图形管理工具方面，Canal确实有自身的优势，而且据说产品内部版本已经对接了商业数据库侧。对于大中型的项目，具有团队开发优势的项目和公司来说，可以考虑，或者可以作为自造轮子的参考。

这几天看了下两个开源项目相关的代码，有了更进一层的认识。GitHub的流行度是一个风向标，

从这个流行度来看，两个项目的量级确实差别挺大，一方面阿里有自身的开源号召力，Maxwell在这个数据面前略显逊色。

不过从代码层面来看，逐步理解了这个差异，首先关于MySQL协议的Java实现，这个整个工具的核心部分，在Canal中都是自下而上都实现了，而Maxwell中翻了一圈代码，竟然没有，发现是在另外一个开源项目mysql-binlog-connector-java中，这个项目的协议实现很精巧，对于理解协议层的一些细节很有帮助。

当然从更细一层来说，Canal是模拟MySQL Slave，主动从Master端拉取日志数据。而mysql-binlog-connector是一个解析库，它有两种模式：BinaryLogFileReader日志读取模式，和BinaryLogClient客户端访问模式，在实现方式上更加灵活，而且BinaryLogFileReader这个部分的实现算是一个杀手级特性，如果规划了binlog集市，在这个基础之上简直如虎添翼。

Maxwell还有什么细节，它基于C3P0连接池，所以在Slave端会看到有几个复制相关的会话，在测试框架部分采用了TestNG的开源项目，在数据落地部分，支持的目标端非常丰富，Redis，Kafka，Kinesis，在数据接入层面的功能非常完善，目前看没有后端的功能支持。

Canal的实现是前后端组合，还包含一个子项目是平台化管理入口，它对接的后端更多是基于自身的技术栈体系，把整个链路能够打通。

对于我们当前的状态来说，我觉得接入Maxwell能够跑通整个数据链路，而且至少在Virtual Slave这一个技术栈上面来说，它是相对技术独立，可以做一些相关的定制工作的，从绝大多数公司的情况来说也是如此，毕竟数据库到大数据的数据流建设相对是隔离的，彼此上下游的建设能够互相映衬，如果目标足够统一，集中优势，选择Canal才是一种长期的策略。