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新消费组上线时可能从头开始消费的问题。

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

嗯，我不告诉你。

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