- LRocccccc 置顶2019-08-02是我理解错了么？为什么场景一二三的图中的SyncGroup请求，都是等待Leader分配方案，leader不应该提供方案么？
作者回复: 嗯嗯，确实是。只是目前Kafka要求所有consumer都发送SyncGroup请求给Coordinator，因为分配方案只能通过SyncGroupResponse的方式获取。图中只是想表示这是一种机制，没有太区分consumer leader和其他consumer
1 
rm -rf 😊ི 置顶2019-07-31老师，在Broker 端重平衡场景剖析这个第一个图里面，既然协调者说了成员2是这个组的leader，为啥成员2的SyncGroup请求会是”等待leader分配“？这是笔误吗？后面几幅图好像也这样。。。作者回复: 只是想表明这是统一的一种机制。。。源代码中肯定没有这样的话。。。
2019-08-01不会超过 session.timeout.ms 就能感知
老师，请问下，消费者已经崩溃了，不会发送心跳，协调者这时候怎么做到能到session.timeout.ms感知的。作者回复: 每次consumer发送心跳时会顺带发送session timeout时间，这样Coordinator收到后会根据这个session timeout时间计算下次deadline时间，如果过了deadline还没有收到直接fail掉该consumer
8
2019-09-09重平衡能不能参照JVM中的Minor gc和Major gc，将重平衡分为两步，在资源的角度讲集群进行分区，这里的资源可以理解为分区，因为后两种变化都是涉及到分区——新主题或已有主题的分区数量变化，对于现有的三种重平衡情况分别做如下处理：
1、新成员入区，在当前区内进行重平衡，不要影响其他的分区
2、资源分区中需要消费的分区队列数量发生的变化，也只是涉及到当前分区的重平衡。
这样设计的话就需要处理一个资源分区太空闲和太繁忙时的问题，我觉得可以参考m树的节点分裂和合并，这么做比m树更简单，因为它没有层级关系，只是资源分区的整合和划分而已，实现的时候还能兼顾到网络的局部特性，当然这只是初步想法，没有详细设计和验证，不知道有没有什么地方没有考虑周全，望老师能指点一二。展开作者回复: 嗯嗯，非常赞的思路。现在社区正在对rebalance进行改革中有很多思想和你也有重合之处。
5
2019-08-06这节课，干货很多，我现在有个疑问，重平衡时需要从消费者实例中选择一个leader，让leader来发起重平衡方案，那为啥不直接让协调者组件来处理呢？作者回复: 客户端自己确定分配方案有很多好处。比如可以独立演进和上线，不依赖于服务器端
4
2019-07-30老师有两个问题请教下：
1）组状态在empty的时候，删除位移信息，这个时间间隔（文中7天）是否可以配置那，还是和普通的默认topic的消息存活时间一样吗？
2）这个设计我有点迷糊，都有协调者了为什么不让协调者统一做订阅分配那，让领导者做不是更麻烦吗？作者回复: 1. 可以配置offsets.retention.minutes
2. 新版本consumer的一个改进就是把分区分配策略从server端移到consumer端来做。Client端代码演进的速度和容易程度要远胜于服务器端，算是一个优势吧 3- 2019-07-30胡老师有没有推荐的jvm 书籍？这块一直没有深入看过
作者回复: 我可不敢误人子弟：） 看看R大推荐的书单吧：https://www.douban.com/doulist/2545443/
1 2 
2019-07-30SyncGroup请求处理流程图中怎么出现了JoinGroup请求？是不是笔误？另外，新成员入组流程图中成员2的SyncGroup请求不应该是“协调者你好，我是成员2，也是这个组的领导者，这是我的分配方案...”吗？作者回复: 感谢纠正，已修改~~
2
2019-10-21老师，看前面也有人问为啥不把订阅分配方案移到协调者上统一去做？ 您说Client端代码演进速度 和 容易程度远胜于服务器端，是一个优势。
这里还是没明白，为什么Client端代码演进速度 和 容易程度更好？！！作者回复: 这只是其中的一个可能的原因。client端代码更新的难度要远小于broker端。如果是broker代码更新，你需要rolling upgrade所有集群中的broker，在生产环境中并不一定有这样的时间窗口
1
2019-10-18老师你好，真实场景中遇到如下问题，请教一下。
跑了一整天的数据，同离线数据按小时粒度相比，大部分小时能对齐数据，查看数据对不起的那个小时的消费者日志，发现如下log，
19/10/15 22:46:00 ERROR ConsumerCoordinator: Offset commit failed.
19/10/15 22:46:00 INFO AbstractCoordinator: (Re-)joining group test_group
rebalance会造成数据丢失么？ 是因为这种rebalance造成的数据丢失？作者回复: 不会造成数据丢失，但可能造成数据重复消费。
1- 2019-09-29多次执行语句：kafka-consumer-groups.sh --bootstrap-server host1:9092 --describe --group group_v1
发现CONSUMER-ID一列，有时候只显示"-"，而且每次CONSUMER-ID的值也不相同。是不是就说明发生了重平衡？作者回复: 显示-是因为消费者有成员没有启动的缘故。另外每次consumer-id不同的确表明每次都是新的member
1 
2019-07-30这一节学到了很多很多，开了视野，感谢 1
2019-07-30请问当重平衡开启时，协调者会给予提交位移的缓冲时间是多少？如果超过了会拒绝提交的位移吗？作者回复: 没有具体的限制。反正如果consumer提交的位移请求到broker端时整个group已经从Preparing进化到Completing了，那么就晚了，broker会拒绝这个提交请求
1
2019-07-30有一个问题：Joingroup响应（成员2，你是这组的leader），Syncgroup请求（我是组员2，请求leader分配方案）。成员2已经是leader了，那么syncgroup的请求信息有点费解，明明已经是leader 还要请求leader分配方案？作者回复: 至少这样能统一机制，因为目前非leader consumer依赖SyncGroup请求才能获取分配方案
1
2020-01-19老师好，我说下自己的愚见。为了 Rebalance 过程避免 STW，是否可以开启另外一个线程用于 ”预分配“，预分配的算法最大化的保证 consumer 实例消费的状态不变，确保 Rebalance 过程只需要变更部分 consumer 实例。预分配成功后，再走真正的 Rebalance 流程，不知是否可行作者回复: 短时间内我不确定这个方案是否可行，大体上看是一个很好的想法。如果可以细化的话，不妨提一个KIP：）
- 2020-01-12老师，有个问题文中说joingroup时等待所有消费者上报订阅信息，协调者通过什么判断所有消费者都已经上报了，或者说怎么知道有多少消费者客户端。如果上报信息后，消费者客户端崩溃了，这能等待下次心跳才能知道吗？
作者回复: join group时也是有一个总的超时时间的（取所有member最大的rebalance超时时间），靠这个作为判断是否进入到下一阶段的阈值。
2019-12-21老师，您好，请教个问题，最近使用consumer消费，发现consumer会出现commit offset failed，coordinator is not available 的错误，导致consumer卡住，无法消费。根据错误信息，是由于找不到groupcoordinator导致的，但coordinator不可以是在什么情况下发生的？一个猜测是由于consumer端发送心跳超时导致groupcoordinator认为该consumer死了，将该consumer剔除该group，导致该consumer不可用，一直卡住，不知道这种解释是否正确作者回复: commit失败先看看是不是消息处理慢导致的吧。比如增加max.poll.interval.ms的值或降低max.poll.records的值试试看。Client端报出Coordinator不可用不一定表示Coordinator真的不可用
2019-11-23文中有一句话：Kafka 定期自动删除过期位移的条件就是，组要处于 Empty 状态。因此，如果消费者组停掉了很长时间，那么 Kafka 很可能就把该组的位移数据删除了
我记得好像默认 7 天会删除消息的啊，为什么一定要 empty 状态呢？不是 empty 状态，过期的就不删除吗作者回复: 是的，不是empty就不删除
2019-11-13老师.好像没有说到订阅主题的分区数发生变化.
分区数变化是指broker挂了,或新增吗.作者回复: 分区数变化是指topic增加了分区
2019-11-081 重平衡的通知
A ：重平衡过程通过消息者端的心跳线程（Heartbeat Thread）通知到其他消费者实例。
B ：Kafka Java消费者需要定期地发送心跳请求到Broker端的协调者，以表明它还存活着。
（1）在kafka 0.10.1.0版本之前，发送心跳请求是在消费者主线程完成的，也就是代码中调用KafkaConsumer.poll方法的那个线程。
这样做，消息处理逻辑也是在这个线程中完成的 ，因此，一旦消息处理消耗了过长的时间，心跳请求将无法及时发到协调者那里，导致协调者错判消费者已死。
（2）在此版本后，kafka社区引入了单独的心跳线程来专门执行心跳请求发送，避免这个问题。
C ：重平衡的通知机制是通过心跳线程来完成的，当协调者决定开启新一轮重平衡后，他会将“REBALANCE_IN_PROGRESS”封装进心跳请求的响应中，发还给消费者实例。当消费者实例发现心跳响应中包含了”REBALANCE_IN_PROGRESS”，就能立即知道重平衡开始了。
D ：消费者端的参数 heartbeat.interval.ms的真实用途是控制重平衡通知的频率。
2 消费者组状态机
Kafka设计了一套消费者组状态机（State Machine），帮助协调者完成整个重平衡流程。
A ：kafka消费者组状态
（1）Empty：组内没有任何成员，但消费者组可能存在已提交的位移数据，而且这些位移尚未过期。
（2）Dead：组内没有任何成员，但组的元数据信息已经在协调者端被移除。协调者保存着当前向它注册过的所有组信息，所谓元数据就是类似于这些注册信息。
（3）PreparingRebalance：消费者组准备开启重平衡，此时所有成员都要重新请求加消费者组
（4）CompletingRebalance：消费者组下所有成员已经加入，各个成员正在等待分配方案。
（5）stable：消费者组的稳定状态。该状态表明重平衡已经完成，组内成员能够正常消费数据了。
B ：Kafka定期自动删除过期位移的条件就是，组要处于Empty状态。如果消费者组停了很长时间（超过7天），那么Kafka很可能就把该组的位移数据删除了。
3 消费者端重平衡流程
A ：重平衡的完整流程需要消费者端和协调者组件共同参与才能完成。
B ：在消费者端，重平衡分为两个步骤：
（1）加入组，对应请求：JoinGroup请求
（2）等待领导者消费者分配方案：SyncGroup请求
C ：当组内成员加入组时，他会向协调者发送JoinGroup请求。在该请求中，每个成员都要将自己订阅的主题上报，这样协调者就能收集到所有成员的订阅信息。一旦收集了全部成员的JoinGroup请求后，协调者会从这些成员中选择一个担任这个消费者组的领导者。
D ：通常情况下，第一个发送JoinGroup 请求的成员自动成为领导者。这里的领导者是具体的消费者实例，它既不是副本，也不是协调者。领导者消费者的任务是收集所有成员的订阅信息，然后根据这些信息，制定具体的分区消费分配方案。
E ：选出领导者之后，协调者会把消费者组订阅信息封装进JoinGroup请求的响应中，然后发给领导者，由领导统一做出分配方案后，进入下一步：发送SyncGroup请求。
F ：领导者向协调者发送SyncGroup请求，将刚刚做出的分配方案发给协调者。值得注意的是，其他成员也会向协调者发送SyncGroup请求，只是请求体中并没有实际内容。这一步的目的是让协调者接收分配方案，然后统一以SyncGroup 响应的方式发给所有成员，这样组内成员就都知道自己该消费哪些分区了。
4 Broker端重平衡场景剖析
A ：新成员入组
当协调者收到新的JoinGroup请求后，它会通过心跳请求响应的方式通知组内现有的所有成员，强制他们开启新一轮的重平衡。
B ：组成员主动离组
消费者实例所在线程或进程调用close()方法主动通知协调者他要退出。这个场景涉及第三类请求：LeaveGroup请求。协调者收到LeaveGroup请求后，依然会以心跳响应的方式通知其他成员。
C ：组成员崩溃离组
崩溃离组是指消费者实例出现严重故障，突然宕机导致的离组。崩溃离组是被动的，协调者通常需要等待一段时间才能感知，这段时间一般是由消费者端参数session.timeout.ms控制的。
D ：重平衡时协调者对组内成员提交位移的处理
正常情况下，每个组内成员都会定期汇报位移给协调者。当重平衡开启时，协调者会给予成员一段缓冲时间，要求每个成员必须在这段时间内快速地上报自己的位移信息，然后在开启正常JoinGroup/SyncGroup请求发送。展开