Kafka处理新扩容partition的漏洞及与RocketMQ的对比

废话不多说,最近使用kafka消费客户端时发现了一个比较严重的风险点、也可以说是漏洞吧,下面详细说明下。

还有另一种参数value为earliest,如果设置为这种方式,表示从所有partiton的最开始位置开始消费。假如一个topic积压了几亿的消息,难道业务刚上线就把这些都消费一遍吗?当然会有业务有这种应用场景。

以上问题的原因是因为,新扩容partition的meta信息被发送端首先获取到,发送端就开始往新partition发送消息,而消费端由于自身的配置导致rebalance比较晚,具体哪些配置导致的我还不清楚,我猜测主要时metadata更新间隔、broker 对消费组延迟rebalance的配置导致的。消费组的rebalance晚于producer发送到新扩容的partition,消费组rebalance后分配到新扩容的partition,寻找到latest的offset,就导致这段时间新发到扩容partition上的消息没有被消费到。这是完全不能接受的!!

你可以理解这是业务正在运行中,仅仅因为扩容了partition而导致消费端消费消息的丢失,这是客户端漏洞或者说是严重bug了。或许kafka会说这是latest的semantic啊,那我只能呵呵。

=======================================================

好吧,看看RocketMQ怎么解决topic扩容问题的,废话不多说,贴一篇我以前的一个文章。

上面这个文章说的是RocketMQ为了解决queue扩容导致的另外一个问题,但是RocketMQ解决了queue扩容时消息丢失的风险。但是它导致了新消费组上线时,可能会从queue的minoffset从头消费,主要策略就是宁可多消费也不能漏消费。因为判断一个partiion/queue是不是新扩容的比较难。

上面RocketMQ和Kafka的实现原理和现象,有疑问吗?他们实现方式各有利弊,不过Kafka的方式应该算是个漏洞。还好我在Kafka的基础上做了封装,既能解决新扩容时消费丢消息的隐患,也能解决RocketMQ新消费组上线时可能从头开始消费的问题。

想知道我是怎么实现的吗?

嗯,我不告诉你。

或许你赏五毛钱我可以告诉你。

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181027G017TO00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券