Kafka中partition，group的具体例子，非代码

最近项目中有用到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_$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上了）