前言
首先，这个文章系列主要是讲canal的，毫无疑问，对吧。那么在开始阅读这个系列之前，我希望真正有兴趣的同学一定要先去阅读canal的官方文档，没有什么比这个更权威了。这篇文章的内容其实也就是摘录自官网的一些文档。
其次，本人对mysql的了解不是特别多，所以纯粹是介绍canal这个工具的大概功能，细节还需要各位各自去研究。
最后，向我们公司的吴大神和庄大神致敬。
canal的工作原理
说明
上面图片内容摘自canal的官方wiki，其实通过这个图我们明白了canal是通过模拟成master的slave来完成数据的同步的，其他后续需要考虑的问题就局限在Canal系统本身了。所以后面应该会针对Canal内部系统进行分析。
canal-server架构
说明
Canal的Server端本身根据配置启动了很多个Instance对象，所谓的Instance对象就是模拟的数据库slave和master进行连接，换句话说就是假设canal同时成为N个数据库的slave，那么就会有N个Instance实例。
每个Instance内部包含5个组件（图中只包含了4个，估计另外一个没有实现的原因），粉笔是eventParser、eventSink、eventStore、metaManager、alarmHandler。其中同步的数据流是按照eventParser->eventSink->eventStore进行传输的，当然eventStore是重点因为它存储了所有从mysql同步过来的数据（数据结构很有意思，后面会介绍），metaManager主要是和zookeeper打交道的，用于记录位点的元信息。
canal数据流
说明
Parser负责负责同步mysql的数据，sink负责进行数据处理并保存到store当中，这也是我刚才提交的数据流，也就说canal的instance里面的三个组件是按照上图进行数据流传输的。
EventStore设计
说明：
EventStore采用内存环装的设计来保存消息，这里面的提交的Disruptor有兴趣可以去看下，这个东西号称无锁队列，性能杠杠的。
EventStore的3个下标分别是put/get/ack，其中put代表同步写入数据的下标，get代表同步获取的数据的下标，ack代表确认数据的下标，这三者的关系是put>=get>=ack。
canal-server内部设计
说明：
canal-server内部其实包含两个server，其中按照server-client模式部署的场景下CanalServerWithNetty负责和client进行交互，CanalServerWithEmbeded负责给CanalServerWithNetty提供服务。
当然我们公司某超大神也直接通过CanalServerWithEmbeded实现了一把独立部署的模式，我抽空会向他进行请教。
server-client交互设计
说明
1、其实在非独立部署下，canal是以server端和client端存在的，server端主要负责同步mysql消息，client负责访问server端消费消息，当然中间会有一些高可用，这个后面到其他章节会有详细讲解。
canal整体架构
说明
一图胜千言，这个图详细的涵盖了canal的系统架构，consumer其实就是client端。
canal部署模式
说明
这个图很好的诠释了canal的工作过程，放在最后算压轴吧，图来自互联网。
最后说说
最后想说说为什么对canal比较感兴趣，首先这个东西在我们公司应用的比较多，其次我们公司的庄大神和吴大神分别采用两种模式在使用这个canal，每次当他们提起这个我就觉得无地自容，因为自己对这个东西一窍不通，然后就通过闲暇时间整理一些文章出来，加深自己的印象，当然这个最后也会有一个专栏叫做canal。
