canal踩坑之路

57 阅读 0 评论 38 点赞

我是靠谱客的博主无心小熊猫，最近开发中收集的这篇文章主要介绍canal踩坑之路，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

上周公司决定使用canal来做binlog日志的解析
结果这件事就落到了我们架构组。
经过研究决定我们架构组将mysql的binlog日志解析为VO对象发送到kafka上，后端业务通过消费对应kafka的日志来拿到对应表的日志信息。
决定了之后就要开始动手做了
开始踩坑之路

原生架构分析
原生架构在1.1之前是不支持将binlog信息直接解析到kafka上的，而且分析完1.0和1.1的代码结构后发现，两者的代码结构相似度在99%左右。
而且两者代码主要的不同在于，1.1对阿里云的数据库原生支持的更好，而1.0对mysql原生支持的更好，而且之前因为在其他公司做过canal的代码开发，因此决定在1.0的基础上进行开发
原生canal的架构是通过zk来保证集群中的canal实例只会有一个实例来工作，并将binlog解析进度保存在zk集群中，从而保证集群中某个实例出现故障时，及时切换为其他的实例，但是并不是实时保存而是延迟一秒保存，因此会出现binlog在主备切换时出现binlog重复解析的问题。
原生的canal的集群架构需要启动一个canal实例，客户端与canal实例建立连接，canal实例只支持单库单实例，并不符合多库多实例的复杂部署情形，而且对于单表的支持并不友好
因此需要在canal原生的基础上进行进一步的封装，从而实现更高的定制化需求
比如：对数据库binlog解析过程中，某些字段需要进行屏蔽，因为某些字段并不能直接给客户端，比如用户的密码信息，
架构优化
对于多实例，多数据库部署时，我们并不需要zk来做主备，我们通过raft协议来动态实现canal实例任务的动态分配和集群健康的检查
对于binlog的解析目的，我们为了拆分canal实例和客户端的强关联，并且提升canal的吞吐量，并未采用，原生canal实例的边解析边保存，发送给客户端，等待客户端响应，保存解析进度的方法，而是采用直接将canal的配置信息保存在数据库中，canal的binlog日志保存也保存在数据库中
对于canal发送的队列，通过查找数据库来实现动态的队列变更，期间加入缓存减轻对数据库的压力
改造处见github
https://github.com/biqingguo/candiess
代码大约落后我们现在使用版本一个版本，而且在实际部署生产的时候发现有一个连接的bug，稍后更新到最新的代码
部署之路
部署的时候发现了一个连接池的bug
当时场景在我当时的开发电脑上，做mysql的binlog解析，百分百成功，但是在部署到实际生产环境的时候发现，并不是每次都成功
最初我们认为是mysql的配置有问题，找dba反复确认后发现配置与开发环境配置一致
排查进入死胡同，然而在我们不知道哪里出问题的时候，重启canal实例发现竟然可以进行正常的解析了，然后在重启发现不能正常的解析，是否可以正常的解析靠运气成分。
然后我们开始tcpdump分析成功和失败的tcp连接有什么不同的地方
发现正常的tcp连接会与mysql建立正常的三个tcp连接，一个心跳保持，一个table解析，一个binlog解析，但是失败的也会建立三个连接，对的没错就是那个解析mysqlbinlog的tcp连接失败了，导致无法正常的解析binlog
数据库一切都是正常的唯一有可能的就是代码有问题了，既然是连接的问题，就查看canal建立连接的源码，通过查看java代码阻塞在哪里发现，第三个连接阻塞在等待mysql返回响应的位置，但是查看tcpdump发现此时mysql已经正常的返回了响应，但客户端阻塞在等待响应这个位置
怀疑建立连接的位置有并发问题，并未拿到真正的tcp连接，而是拿到了，其余两个tcp连接，而这两个tcp连接因为是正常的，而此时第三个线程并没有拿到任何的响应，所以死在等待响应的位置。
通过比较1.0和1.1在连接管理上的不同处，发现在1.1已经将1.0连接管理的方法废弃，采用了另外的方法，因此决定将1.0的版本连接管理方法重写为1.1
改写为1.1的后发现，没错确实就是这个位置的代码存在并发问题，而且1.0的代码在连接管理上并未存在连接超时的概念，而在1.1的版本上加入了超时管理，但是现在问题已经解决，只能先这样交付个业务部门，然后在慢慢将代码升级到最新的1.1
但是1.1版本并不建议直接用，因为里面做了大量的兼容阿里云的db协议的改动，为了更好的兼容阿里云自己的db而不是更好的兼容开源的mysql
总结
开源的并不是没有bug的，都是别人从自己的角度出发，适配自己的需求做的改变，因此善用开源
多阅读一些开源代码，从里面吸取自己需要的东西，而不是盲目使用