前言
首先,这个文章系列主要是讲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。