最近项目中有用到Kafka,之前看网上博客大体上都还比较清楚。其中消费者group和生产者的partition的对应关系,在之前自己的项目中比较重要,就做了一下测试。在此记录一下。
发送到Kafka的消息会根据key,发送到对应topic的partition中,有默认的分发规则(也可以自己重写分发规则),基本上就是相同的key发送到一个partition中,不同的key有可能发送到相同的partition中。
group是消费者中的概念,按照group(组)对消费者进行区分。对于每个group,需要先指定订阅哪个topic的消息,然后该topic下的partition会平均分配到group下面的consumer上。所以会出现以下这些情况:
1、一个topic被多个group订阅,那么一条消息就会被不同group中的多个consumer处理。
2、同一个group中,每个partition只会被一个consumer处理,这个consumer处理的消息不一定是同一个key的。所以需要在处理的地方判断。
举个例子,现在有一个用户信息修改的回调消息扔到消息队列里,有两个业务要处理,一个是更新数据库,一个是更新es索引信息
topic:user_update_topic
key:user_update_key_
c
i
d
cid
cid //cid标志公司的区分信息
这样子的话,同一个公司的用户更新会被分配到一个partition中,同一个公司的用户更新能保证前后顺序不变
group1中的consumer处理更新db,group:consumer1_group
group2中的consumer处理更新es,group:consumer2_group
group1,group2这个两个group会分别消费这个topic下的数据,对于每个group,内部的consumer会平分topic下的partition,相当于group中的每个consumer会处理多个公司的数据,但处理的公司不会有重叠
注:以上更新db,更新es的操作其实不需要分开两个,可以在一个consumer中处理,或者监控数据库的binlog去更新es。此处暂时想不到其他例子了
以上是topic中partition多余group中的消费者的时候,如果group下面有3个消费者,但是分区partition只有一个,那么三个消费者中只有一个会消费消息。
20180622更新
如果开启了rebalance。group下有consumer1订阅了topic1,group下有consumer2,consumer3订阅了topic2.当group中的consumer发生了变化,增加或者减少。同一个group中的topic1 和 topic2 都会做重新分配partition。例如consumer2消失了,topic1在group中重新分配(虽然没有变化),topic2在group中重新分配(都集中到consumer3上了)