刚刚在群里看到消息说，时隔一年，canal 1.1.6正式release了，赶紧上去看看有什么新特性。
(居然才发布了6个小时，前排围观)
一、什么是canal
canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据 订阅 和 消费。应该是阿里云DTS(Data Transfer Service)的开源版本。
如果想了解更多，可以上github上看官方文档，或者我之前写过的系列基于canal 1.1.4版本的入门文档。
二、重要新特性
我们现在生产用的还是1.1.4版本，用得还算稳定，没有什么特别大的bug。
这次，趁着升级了两个版本，看看1.1.5和1.1.6版本有什么新特性可以值得升级引入。
1、MQ发送优化
重点优化MQ发送的性能，单topic最高峰值可支持3~8万的rps，接近数量级上的性能提升
这是1.1.5中的重要特性优化。
为什么canal需要搭配MQ使用，甚至重点优化MQ的投递性能呢?
主要原因是 canal + MQ 可以打造强大的异构存储体系。
canal订阅binlog后有两种模式，一种是直接投递到一种介质，如mysql，一种是投递到MQ然后自定义消费。
如果采用投递到MQ的模式，那么我们就可以利用MQ进行一份消息多端消费(避免重复拉取binlog对MySQL造成影响)，用于构建二级索引ES或者构建缓存Redis等等。
另一方面，投递mq以后，对于消息的回溯、监控都能提供更好的途径。
总的来说，canal这个特性优化给 canal + MQ 的模式带来了更加强大的支持。
2、MQ发送特性支持
新增rabbitmQ的MQ发送支持 #2156。
支持不同topic设置不同的分区数 #2173。
rocketMQ新增tag属性的定义 #3438。
参数配置支持env环境变量 #3450。
这是1.1.5中的一个小优化，但是我觉得非常重要。
比如rocketMQ新增tag属性的定义。实际上在我们的测试环境，就非常需要这个特性。
我们使用rocketMQ的tag做路由，如果业务方自行生产和消费，可以完全根据tag进行路由区分。而从canal订阅的数据库变更，1.1.4版本无法直接给消息打tag，业务消费就无法通过tag进行路由。
现在这个特性的优化，正好可以解决这个问题。
3、新增Puslar MQ支持
这是1.1.6中的一个小优化，还是非常与时俱进的。
目前的云原生消息队列Puslar MQ，凭借存储和计算分离的架构在云原生体系下如日中天，而canal就在最新版本支持了对Puslar MQ的投递，手动点赞。
三、重要bug修复
1、修复gtid模式下位点持久不更新的问题
这是1.1.5中修复的bug。
GTID又叫全局事务ID(Global Transaction ID)，是一个已提交事务的编号，并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。
为什么要引入这个东西呢?
- GTID使用master_auto_position=1代替了基于binlog和position号的主从复制搭建方式，更便于主从复制的搭建。
- GTID可以知道事务在最开始是在哪个实例上提交的。
- GTID方便实现主从之间的failover，再也不用不断地去找position和binlog 了。
为什么我特别关注到这个bug的修复呢?
因为我在2020年对canal 1.1.4进行poc的时候，就发现这个bug了，当时还吐槽了一波，233333。
一晃两年过去了，没想到在1.1.5中已经修复了，手动点赞。
2、修复RDB同步下的关键字引起的同步报错
这是1.1.6中修复的bug。
对于这个bug，也是有点记忆犹新。
当时在莫干山度假，突然早上八点收到线上警报，发现数据同步出现异常。
好在随身带了电脑(程序员出远门必备，sigh~)，经过排查后发现，就是一个表结构变更引入的关键字导致了同步异常。
往事不堪回首。。。
四、总结
这里简单介绍了几个对我们生产中比较重要的优化和修复，具体更多内容大家可以直接去github上看release note。
总的来说，1.1.5和1.1.6都做了非常多的bug修复和特性优化，还是非常值得升级的。
免责声明：本平台仅供信息发布交流之途，请谨慎判断信息真伪。如遇虚假诈骗信息，请立即举报
举报
