.net Kafka.Client多个Consumer Group对Topic消费不能完全覆盖研究总结（一）

我们知道Kafka支持Consumer Group的功能，但是最近在应用Consumer Group时发现了一个Topic 的Partition不能100%覆盖的问题。

程序部署后，发现Kafka在pdb组的consumer消费topic时存在问题，consumer无法完全覆盖Topic的各个partition。如下图：

frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;"> frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;"> frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;">

frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;">

无论我在开启多少个consumer实例，最高覆盖只能达到66%。

进一步跟踪发现，pdb组的consumer覆盖到partition1和partion2.

frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;">

在kafka的主消费组defaultGroup中的consumer，覆盖partition0

frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;">

根据以上现象猜测，当有多个消费者组对topic进行消费时,存在partition的竞争机制在里面。

为验证partion是否存在竞争，关掉测试程序，default group中的consumer覆盖恢复100%。

如下图。

frameborder="0" scrolling="no" style="border-width: medium; width: 1px; height: 1px;">

翻阅官方文档，有提到

1、同一个partition不支持comsumer并发。

2、不同gourp组中的consumer，可以对同一个topic进行消费。

同时在spark的kafka插件中，对同一topic的消费者，不同组都可以达到100%的覆盖率。

在本地做测试，同样存在该问题。

不同组的消费者对同一个topic进行消费时，两个消费者都达不到100%覆盖率（每个组的消费者总有一些数据消费不到）。

在中文社区翻阅所有的消费者和连接以及流的配置项，暂未发现影响该问题的配置项（http://orchome.com/kafka/index kafka中文社区地址。）。

关于该问题的研究暂时没有结论，暂未确定是配置不合适或kafka.Client 存在问题，后续会持续跟踪该问题。

通过该次问题的研究，对kafka消费组、消费者、连接流、partion和consumer映射关系、parttion 分配策略有了较为深入的了解，唯一遗憾的是未找到关于该问题的官方解释和相关说明。

附，Kafka-Partion和consumer重新Rebalance算法如下：

将目标Topic下的所有Partirtion排序，存于PT
对某Consumer Group下所有Consumer排序，存于CG，第i个Consumer记为Ci
N=size(PT)/size(CG)，向上取整
解除Ci对原来分配的Partition的消费权（i从0开始）
将第i∗N到（i+1）∗N−1个Partition分配给Ci

　　目前，最新版（0.8.2.1）Kafka的Consumer Rebalance的控制策略是由每一个Consumer通过在Zookeeper上注册Watch完成的。每个Consumer被创建时会触发Consumer Group的Rebalance，具体启动流程如下：

High Level Consumer启动时将其ID注册到其Consumer Group下，在Zookeeper上的路径为/consumers/[consumer group]/ids/[consumer id]
在/consumers/[consumer group]/ids上注册Watch
在/brokers/ids上注册Watch
如果Consumer通过Topic Filter创建消息流，则它会同时在/brokers/topics上也创建Watch
强制自己在其Consumer Group内启动Rebalance流程

　　在这种策略下，每一个Consumer或者Broker的增加或者减少都会触发Consumer Rebalance。因为每个Consumer只负责调整自己所消费的Partition，为了保证整个Consumer Group的一致性，当一个Consumer触发了Rebalance时，该Consumer Group内的其它所有其它Consumer也应该同时触发Rebalance。