爷青回，Canal1.1.6来了，几个重要特性和bug修复

刚刚在群里看到消息说，时隔一年，canal 1.1.6正式release了，赶紧上去看看有什么新特性。

(居然才发布了6个小时，前排围观)

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。应该是阿里云DTS(Data Transfer Service)的开源版本。

如果想了解更多，可以上github上看官方文档，或者我之前写过的系列基于canal 1.1.4版本的入门文档。

我们现在生产用的还是1.1.4版本，用得还算稳定，没有什么特别大的bug。

这次，趁着升级了两个版本，看看1.1.5和1.1.6版本有什么新特性可以值得升级引入。

重点优化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 的模式带来了更加强大的支持。

新增rabbitmQ的MQ发送支持 #2156。
支持不同topic设置不同的分区数 #2173。
rocketMQ新增tag属性的定义 #3438。
参数配置支持env环境变量 #3450。

这是1.1.5中的一个小优化，但是我觉得非常重要。

比如rocketMQ新增tag属性的定义。实际上在我们的测试环境，就非常需要这个特性。

我们使用rocketMQ的tag做路由，如果业务方自行生产和消费，可以完全根据tag进行路由区分。而从canal订阅的数据库变更，1.1.4版本无法直接给消息打tag，业务消费就无法通过tag进行路由。

现在这个特性的优化，正好可以解决这个问题。

这是1.1.6中的一个小优化，还是非常与时俱进的。

目前的云原生消息队列Puslar MQ，凭借存储和计算分离的架构在云原生体系下如日中天，而canal就在最新版本支持了对Puslar MQ的投递，手动点赞。

这是1.1.5中修复的bug。

GTID又叫全局事务ID(Global Transaction ID)，是一个已提交事务的编号，并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。

为什么要引入这个东西呢?

为什么我特别关注到这个bug的修复呢?

因为我在2020年对canal 1.1.4进行poc的时候，就发现这个bug了，当时还吐槽了一波，233333。

一晃两年过去了，没想到在1.1.5中已经修复了，手动点赞。

这是1.1.6中修复的bug。

对于这个bug，也是有点记忆犹新。

当时在莫干山度假，突然早上八点收到线上警报，发现数据同步出现异常。

好在随身带了电脑(程序员出远门必备，sigh~)，经过排查后发现，就是一个表结构变更引入的关键字导致了同步异常。

往事不堪回首。。。

这里简单介绍了几个对我们生产中比较重要的优化和修复，具体更多内容大家可以直接去github上看release note。

总的来说，1.1.5和1.1.6都做了非常多的bug修复和特性优化，还是非常值得升级的。

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容