耿斌 置顶2019-07-23“显然，Rebalance 之后的分配依然是公平的，即每个 Consumer 实例都获得了 3 个分区的消费权。”
这里应该是每个Consumer实例都获得了2个分区的消费权
有个问题，Consumer group是可以任意指定创建的？作者回复: 感谢纠正：）
可以任意指定创建
2019-07-06消费组中的消费者个数如果超过topic的分区数，就会有消费者消费不到数据。但如果是同一个消费组里的两个消费者通过assign方法订阅了同一个TopicPartition，是不是会有一个消费者不能消费到消息？作者回复: 如果使用assign，则表明该consumer是独立consumer（standalone consumer），它不属于任何消费者组。独立consumer可以订阅任何分区，彼此之间也没有关系，即两个独立consumer可以订阅并消费相同的分区
12
2019-07-08如何避免rebalance发生？我发现线上在没有这三种情况也会发生，我猜是网络瞬断导致的，但不知道kafka是否会发生定时的rebalance？谢谢了作者回复: 网络断了，心跳中断，consumer被踢出组，也属于第一种情况
7
2019-07-06请老师讲讲手动管理consumer offset的工程实践作者回复: 专栏后面有专门的内容：）
6
2019-07-06老师最后那个Rebalance例子有问题吧，最后每个consumer只有两个而不是三个吧作者回复: 嗯嗯，不就是每个consumer分配两个吗？
2 6
2019-07-06什么时候来个consumer端手动管理offset的方案 4 6
2019-07-11发布 / 订阅模型倒是允许消息被多个 Consumer 消费，但它的问题也是伸缩性不高，因为每个订阅者都必须要订阅主题的所有分区。这种全量订阅的方式既不灵活，也会影响消息的真实投递效果。
问题：
1、每个订阅者都必须要订阅主题的所有分区，是否意味着每个订阅者都需要消费所有的分区的所有消息？
2、我理解一个主题下进行分区消费就可以满足日需求了，Consumer Group为什么设计成可以订阅多个主题，什么样的场景会使订阅多个主题？
谢谢。作者回复: 1. 不会。每个订阅者分配一部分分区消费
2. 没有什么规定要求什么场景下需要订阅多个主题。事实上，对于默认的分区策略，一个组订阅多个主题的做法会导致分配的极不均匀，但我们依然还是能够找出一些场景，使得这么做是有意义的。比如消费者组订阅多组传感器的数据，我们不确定未来新增传感器的主题名到底是什么，但可以约定所有传感器的主题名以sensor开头，那么此时让group订阅以sensor开头的所有主题就能动态地检测后续新增的主题。这个场景是不是有意义些？ 5
2019-07-06难得一个双休，今天终于学习到这篇了，好想实战上手玩一玩Kafka。老师，最后一个章节才会有实战Demo吗？ 5
2019-07-06我们现在服务是3个topic，每个topic有64个分区，6个消费实例，每次服务重新部署（6个实例依次关闭启动）都会导致长时间的rebalance，是否减少topic的分区数可以减少服务部署时rebalance的时间呢？作者回复: 嗯，会的。减少consumer个数也有缩短rebalance。
4
2019-07-31会不会存在这样一个情况：一个consumer正在消费一个分区的一条消息，还没有消费完，发生了rebalance(加入了一个consumer)，从而导致这条消息没有消费成功，rebalance后，另一个consumer又把这条消息消费一遍作者回复: 非常可能存在
2 3
2019-12-19传统消息引擎的弊端
传统的消息引擎主要有2种模式：点对点模式 和 发布/订阅模式
但是不管是点对点模式，还是发布/订阅模式，队列发消息的能力是一定的：即某队列发完积压的所有消息的时间是有上限的，最短的时间是：消息数量*发送单个消息的时间
并且，传统消息引擎的“弹性”比较差，如果是消息引擎主动推送消息，很有可能会造成消费者端积压了很多的消息，那么，这和消息引擎的初衷“削峰填谷”是相违背的。如果是消费者主动拉取消息，可能造成多个消费者抢一条消息的情况。
另一个方面是，传统消息队列的容错性比较差。消息发送完成，就从队列移除了，没有办法重新消费。
Kafka是如何解决的
Kafka引入了主题，分区，消费者组，消费者，位移的概念，来解决扩展性和容错性问题。
试想，如果我们要提高传统消息引擎的TPS，在计算机I/O能力一定的情况下，只能通过增加节点的方式，使得多个节点构成一个消息队列。那么对应到Kafka里面，节点就是分区，消息队列就是主题。
同时引入位移的概念，解决了消费者端消息积压的问题。并且有多个消费者组成消费者组，提高消费能力。这也就解释了，为什么kafka某个主题下的单个分区只能分配给消费者组内的一个消费者。从逻辑上讲，如果分配给同组内的2个消费者，就相当于重复发送了2次消息，这是没有必要的。
Kafka这么做相当于把原本"串行"的消息发送"并行"化，因此TPS大大提升。
Kafka的缺点
缺点主要是Rebalance 过程，耗费的时间巨大，并且目前也没有什么好的解决办法，最好就是尽量减少Rebalance 的过程。
最后
也不是说传统消息引擎就该淘汰了，还是得看具体的业务场景。但是在大数据处理方便，Kafka是具有优势的。
（不知道理解的对不对，还望老师指正）展开作者回复: 总结得非常全面了：）
2
2019-11-02Consumer Group ：Kafka提供的可扩展且具有容错性的消息者机制。
1，重要特征：
A：组内可以有多个消费者实例（Consumer Instance）。
B：消费者组的唯一标识被称为Group ID，组内的消费者共享这个公共的ID。
C：消费者组订阅主题，主题的每个分区只能被组内的一个消费者消费
D：消费者组机制，同时实现了消息队列模型和发布/订阅模型。
2，重要问题：
A：消费组中的实例与分区的关系：
消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。
B：消费者组的位移管理方式：
（1）对于Consumer Group而言，位移是一组KV对，Key是分区，V对应Consumer消费该分区的最新位移。
（2）Kafka的老版本消费者组的位移保存在Zookeeper中，好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架，不适合进行频繁的写更新，这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。
（3）Kafka的新版本采用了将位移保存在Kafka内部主题的方法。
C：消费者组的重平衡：
（1）重平衡：本质上是一种协议，规定了消费者组下的每个消费者如何达成一致，来分配订阅topic下的每个分区。
（2）触发条件：
a，组成员数发生变更
b，订阅主题数发生变更
c，定阅主题分区数发生变更
（3）影响：
Rebalance 的设计是要求所有consumer实例共同参与，全部重新分配所有用分区。并且Rebalance的过程比较缓慢，这个过程消息消费会中止。展开作者回复: 专栏结束了把你的分享笔记share出来吧：）
2
2019-07-08老师，rebalance的时候可以不可以这样做，如果是consumer挂掉导致，那不做group的rebalance，仅仅是将挂掉节点上的partition重新分配给别的consume让，只有在consumer消费特别不均匀的情况下才做group的rebalance；
如果是添加节点导致rebalance，那也不用一次性就做，可以分阶段，比如说先把消费压力大的consumer上的partition分一部分给新进来的consumer！ 1 2
2019-07-07举个简单的例子，假设一个 Consumer Group 订阅了 3 个主题，分别是 A、B、C，它们的分区数依次是 1、2、3，那么通常情况下，为该 Group 设置 6 个 Consumer 实例是比较理想的情形，因为它能最大限度地实现高伸缩性。
你可能会问，我能设置小于或大于 6 的实例吗？当然可以！如果你有 3 个实例，那么平均下来每个实例大约消费 2 个分区（6 / 3 = 2）；如果你设置了 8 个实例，那么很遗憾，有 2 个实例（8 – 6 = 2）将不会被分配任何分区，它们永远处于空闲状态。因此，在实际使用过程中一般不推荐设置大于总分区数的 Consumer 实例。设置多余的实例只会浪费资源，而没有任何好处。
老师，针对上面这段例子有一个问题: 如果8个实例，6个分区，每个实例负责分配一个分区，多出来的2个实例不能与其他消费实例共同负责一个分区吗？展开作者回复: 如果它们都属于同一个消费者组，那么不能。消费者组订阅的分区只能被组内一个consumer实例消费。
2- 2020-01-17老师,一个consumer group中的consumer中订阅的topic必须是完全一样的吗?如果可以自行订阅,那么分配topic分区的时候是怎么分配的?比如consumer group包含consumer1,consumer2,consumer3,其中只有consumer3订阅了topic3,那topic3的分区是会只分配给consumer3还是会平均分配给consumer1,consumer2,consumer3?
作者回复: 不要求一样。分配取决于你用什么策略，默认策略你基本上可以认为是平均分配。
1 
2019-11-30订阅topic是在消费者程序中实现的，如果一个group内多个消费者分别订阅了不同的topic，是不是所有这些topic下的全部分区都会统一分配这个group内的消费者？比如group内消费者A只订阅topic1，但是topic2（被另一个消费者订阅）下的某一个分区却分配给了消费者A？作者回复: 不会的。分配的原则还是要考虑每个consumer的订阅情况。不可能把你没订阅的分区分给你
1- 2019-10-22文中提到，同一个Group中的不同Consumer实例负责消费Topic的不同分区。
有一个问题，同一个Group中的不同Consumer实例可以订阅不同的Topic吗？作者回复: 可以的。虽然在实际使用中可能更多的还是同一个group的多个实例订阅相同的topic。
1 
2019-10-14胡老师好，有一个rebalance的问题请教一下：
假设一个topic有P1和P2两个分区， 由同一消费者组中的C1和C2消费， C1消费P1, C2消费P2。
C1和C2都是手动管理offset的，消息消费后，会将offset保存到mysql中，然后commit到broker
某一时刻，C1 offset到100 消费完成后保存mysql, 但是没有调用commitSync()
C2 offset到200, 消费完成后保存offset到mysql, 但是没有调用commitSync()
然后发生了rebalance， rebalance后，C1分配到P2分区，C2分配到P1分区。
之后，C1和C2调用commitSync(), （其实是commit rebalance前的分区的offset）,会发生什么情况？展开作者回复: 如果你没有实现ConsumerRebalanceListener接口中的方法显式从MySQL中恢复offset，那么rebalance回来后会从Broker中读取Kafka这边保存的已知的最新位移，但很可能不是你MySQL中保存的位移，因此此时调用commitSync没有什么效果。
1
2019-08-26elasticsearch在增加分片和减少分片时也有类似的重平衡的过程。es需要迁移数据所以时间会很长，kafka又不用迁移数据为什么要几个小时?看起来只是分区ID重新哈希一下?耗时主要在哪里？作者回复: kafka增加了分区手动迁移的话也要迁移数据的
2 1
2019-08-15老师好，我有以下几个疑问，请帮忙解答一下，多谢!
1：请问老师，什么场景下消费者组中的一个实例会是一个进程中的线程呢？
2：传统的消息队列模型的缺陷在于消息一旦被消费，就会从队列中被删除，而且只能被下游的一个 Consumer 消费。
请问老师，这里描述的删除操作，具体是什么操作？将消息从队列中移出？还是移动位移标识此位置可以使用？这些操作应该是内存中的吧！对于落盘的消息以及副本中的消息也有删除的动作吧？删除一个消息的完整流程是怎么样的呢？
3：发布 / 订阅模型倒是允许消息被多个 Consumer 消费，但它的问题也是伸缩性不高，因为每个订阅者都必须要订阅主题的所有分区。这种全量订阅的方式既不灵活，也会影响消息的真实投递效果。
如果一个主题可以有多个分区，也能增加分区数据，如果消费能力不足，可以增加消费者，这种方式没理解怎么伸缩性就不高了？不是一个consumer实例只能消费主题下的一个分区嘛？展开作者回复: 1. 如果你的client端机器非常强劲，只启动一个consumer实例单线程消费未免有些浪费，你可以以启动多个线程的方式来充分利用资源。
2. 消息被删除。具体流程因不同框架而定
3. 1个consumer必须订阅所有分区，这是不必要的 1