深入Canal解构消息队列单点性能瓶颈

本文讲述了在使用Canal订阅binlog过程中遇到的消息默认发送问题,作者通过探索解决方案、深入源码分析,最终发现并解决分区配置导致的单点性能问题,揭示了DDL操作的特殊行为。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 业务场景

在使用Canal订阅binlog的过程中,我们观察到一个现象:尽管有大量的Topic,消息却默认发送到MQ的第一个队列。这导致当消费者服务启动并查询动态注册的消费者时,只有最先启动的消费者能够注册大量消费者,进而造成单点性能问题。

2. 解决方案探索

首先想到的是从消费者端进行负载均衡

思路1:

原来的消费者服务作为代理服务,负责转发消息到新的Topic,然后新增一个消费者服务,消费新的Topic

逻辑处理清晰易懂,但是需要新增一个服务

思路2:在原来的消费者服务基础上,进行负载均衡,按照表名进行Hash。不同的服务消费对应的Topic

目测可行,由于下面找到问题的根本原因,所以没试

3. 深入Canal源码

在我开始阅读Canal的源码时,我们发现在初始化canalMQProducer.init时,会构建一个线程池,这个线程池管理着对不同RocketMQ队列的消息发送任务。进一步的研究让我们找到了partitionsNum和partitionHash这两个关键的参数配置在这里插入图片描述
下面贴出我们生产上当时的配置

canal
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值