：在消费者重新加消费者组后，Kafka集群会将分区分配方案应用到实际的分区分配中，重新分配主题分区给消费者恢复消费：最后，Kakfa会恢复所有消费者的拉取动作，允许它们消费分配给自己的分区Kafka的重平衡机制能够有效地实现消费者的负载均衡和高可用性...消费者的五种状态Kafka的Consumer实例的五种状态，分别是：状态描述Empty组内没有任何成员，但是消费者可能存在已经提交的位移数据，而且这些位移尚未过期Dead同样是组内没有任何成员，但是组的元数据信息已经被协调者端移除...，协调者保存着当前向他注册过的所有组信息PreparingRebalance消费者组准备开启重平衡，此时所有成员都需要重新加入消费者组CompletingRebalance消费者组所有成员已经加入，各个成员中等待分配方案...Stable消费者组的稳定状态，该状态表明重平衡已经完成，组内成员能够正常消费数据状态的流转过程：Kafka几种选举过程 在Kafka中常见的几种选举过程如下：Partition Leader选举Kafka...当Leader副本宕机或者无法正常工作时，需要选举新的Leader副本来接管分区的工作。
《Kafka重要知识点之消费组概念》讲到了kafka的消费组相关的概念，消费组有多个消费者，消费组在消费一个Topic的时候，kafka为了保证消息消费不重不漏，kafka将每个partition唯一性地分配给了消费者...当kafka遇到如下四种情况的时候，kafka会触发Rebalance机制： 消费组成员发生了变更，比如有新的消费者加入了消费组组或者有消费者宕机 消费者无法在指定的时间之内完成消息的消费 消费组订阅的...在这一节，笔者熟悉了会触发kafka Rebalance机制的第二种情况以及应对措施，接下来，笔者将深入介绍kafka的重平衡机制 2....partition重新分配给其它的消费者，如果TimeoutConsumer完成了消息的消费，假设TimeoutConsumer成功提交partition的offset，那么就会出现混乱，因为TimeoutConsumer...负责的partition已经被分配给了其它的消费者。
2 分组消费再平衡策略 当一个group中,有consumer加入或者离开时,会触发partitions均衡partition.assignment.strategy,决定了partition分配给消费者的分配策略...分组消费有一个比较好的功能就是自动检测失败的消费者并将其踢出分组，然后重新进行分区分配。...消费着订阅了一组的topic后，会在调用poll(long)函数的时候加入分组，分组内新增消费者就会进行再平衡。Poll 函数的设计目标就是来保证消费者存活的。...如果消费者挂掉或者无法在session.timeout.ms时间范围内发送心跳，消费者会被视为死亡，它的分区就会被重新分配。session.timeout.ms默认是10000ms。...当然，弊端是增加该值会增加消费者组再平衡的时间，因为仅仅在调用poll的过程中消费者才能参与再平衡。
2.4.0的另一个新功能:static membership功能 成员加入或成员离组是最常见的触发重平衡的情况。...一旦配置了该参数，成员将自动成为静态成员，否则的话和以前一样依然被视为是动态成员。 静态成员的好处在于，其静态成员ID值是不变的，因此之前分配给该成员的所有分区也是不变的。...如果活动的使用者为主题分区提交了偏移量以来已经过了相应的保留期或更长时间，则将从使用者组元数据中删除该已提交的偏移量。...一旦配置了该参数，成员将自动成为静态成员，否则的话和以前一样依然被视为是动态成员。 **静态成员的好处在于，其静态成员ID值是不变的，因此之前分配给该成员的所有分区也是不变的。...当有新成员加入时肯定会触发 Rebalance 重新分配分区 - Leader 成员重新加入组：比如主题分配方案发生变更 - 现有成员离组时间超过了 `session.timeout.ms` 超时时间：
如果分区数量无法被整除地分配给消费者数目，最后一个消费者可能会获得稍多于其他消费者的分区，以确保所有分区都分配出去。...以下是RoundRobin分区分配策略的详细原理： 消费者加入Group：当一个新的消费者加入Consumer Group时，或者已经存在的消费者需要重新平衡分区，Group Coordinator（...这是策略名称"Sticky"的来源，因为它试图将分区"粘"在已经处理它的消费者上。 分区重新平衡：如果有新的消费者加入消费者组，或者有消费者离开，系统需要执行分区再分配。...重新平衡的触发：重新平衡可以由以下几种情况触发： 消费者加入或退出消费者组。 消费者心跳超时。 某个分区失去联系的情况下，可能会重新分配。...Sticky策略的主要优点是减少了分区再分配的频率，减轻了系统的不稳定性，降低了重新平衡的成本。这对于大规模的Kafka集群和高吞吐量的消费者组特别有用。
Kafka 有两个默认的分配策略： Range：该策略会把主题的若干个连续的分区分配给消费者。 RoundRobin：该策略把主题的所有分区逐个分配给消费者。...两个消费者群组对应一个主题： 当一个消费者被关闭或发生崩溃时，它就离开群组，原本由它读取的分区将由群组里的其他消费者来读取。分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再均衡。...在消费者机器重启过程中，存在partition和消费者重新建立联系的情况，比如最开始有4个消费者，由于并行重启消费者，可能存在一段时间消费者数量变为2个，当重启完成后消费者数量有变成了4个。...选举设计 先说分区leader的选举，就是当ISR中的leader副本挂了，再重新选举一个过程。...如果由于某种原因leader消费者退出消费组，需要重新选举leader，消费者协调器维护一个map结构，key为消费组id，value为消费者元信息，默认选择第一个key作为leader。
这是通过在消费者组中平衡分区分配来实现的，这使得每个分区仅仅被分配给消费者组的一个消费者。比如，一个topic有四个分区，一个消费者组有两个消费者，那么每个消费者将会拥有两个分区。...消费者组和分区的关系是动态的。这时候有一个消费者组再平衡的策略。...如果消费者宕机或者不能在超时时间(session.timeout.ms)内发送心跳，那么消费者就会被认为死掉了，它的分区会被重新分配给其它分区。...假如你不能在最大间隔内调用poll，消费者会主动离开消费者组，所以它占用的分区就会分配给其它消费者。这种情况下你会发现消费者抛出提交失败异常。...2),缺点：无法保证分区内消息处理的顺序。 3),缺点：手动提交偏移变得困难，因为需要所有的线程协调工作，保证消费的每个分区的消息处理完毕，才能提交分区的偏移。 这种方式可以进行简单变化。
它使用一个实现了PartitionAssignor接口的类来决定哪些分区应该被分配给哪个消费者。 分配完毕后，群主把分配情况列表发送给群组协调器，协调器再把这些信息发送给所有消费者。...GroupMetadataManager：负责管理 GroupMetadata以及消费偏移量的提交，并提供了一系列的组管理的方法供组协调器调用。...，心跳检测正常 Dead：处于该状态的消费组没有任何消费者成员，且元数据信息也已经被删除 Empty：处于该状态的消费组没有任何消费者成员，但元数据信息也没有被删除，知道所有消费者对应的消费偏移量元数据信息过期...DelayedJoin：延迟操作类，用于监视处理所有消费组成员与组协调器之间的心跳超时 GroupConfig：定义了组成员与组协调器之间session超时时间配置 3....在再均衡期间，消费者无法读取消息，造成整个群组一小段时间的不可用。另外，当分区被重新分配给另一个消费者时，消费者当前的读取状态会丢失，它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。
在重平衡期间，消费者无法读取消息，造成整个消费者组在重平衡的期间都不可用。...另外，当分区被重新分配给另一个消费者时，消息当前的读取状态会丢失，它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。...重平衡是一把双刃剑，它为消费者群组带来高可用性和伸缩性的同时，还有有一些明显的缺点(bug)，而这些 bug 到现在社区还无法修改。 重平衡的过程对消费者组有极大的影响。...也就是说，在重平衡期间，消费者组中的消费者实例都会停止消费，等待重平衡的完成。而且重平衡这个过程很慢.........第三行代码非常重要，Kafka 必须定期循环请求数据，否则就会认为该 Consumer 已经挂了，会触发重平衡，它的分区会移交给群组中的其它消费者。
另一方面，这样做的缺点是增加了分区的不可用性，因为协调代理可能只在几分钟后才检测到失败的使用者(取决于session.timeout.ms)。...注意:使用增量协作再平衡，当成员接收到新的分配时，它将开始处理任何新的分区(或任务/连接器)。此外，如果赋值还包含被撤销的分区，那么它将停止处理、提交，然后立即启动另一个join组。...这样做的效果是增加了重新平衡的数量，但只会停止分配发生变化的资源。 ? 4 - W1, W3接收任务 W2在延迟到期之前重新加入组，并触发另一个再平衡。W1和W2也重新加入这个组。 ?...5 - B在延迟到期前重新加入组，并触发再平衡 但是，在计划的重新平衡延迟到期之前，W1不会重新分配丢失的任务/连接器。 ?...静态成员关系和增量协作再平衡都是重要的特性，它们使Apache Kafka协议更加健壮和可伸缩，从而为其提供了巨大的改进。 要了解更多关于再平衡协议及其工作原理，请查看以下链接。
将分区重新分配给消费者的情况也会发生在topic被修改的情况中，如增加新的分区。 将分区的所有权从要给消费者转移到另外一个消费者被称之为分区重平衡。...在本章中，我们将讨论如何安全的处理平衡以及如何避免不必要的重平衡。 消费者维护消费者组中的成员关系和分配给他们的分区所有权的方法是将心跳发送到指定的broker的组协调器coordinator。...但也可能导致不必要的重平衡，因为消费者完成轮询循环或者垃圾收集的时间会更长。设置session.timeout.ms过高，虽然会减少意外带来的重平衡，但是也意味着需要更长的时间来检测真正的故障。...如果时，则没有更新的提交，可以安全的重试，如果实例序列号较高，则不需要重试，因为已经有新的提交了。...然后我们指定我们完成了记录的处理，并提交了offset，要么没有提交成功，将重新处理。
分区器 消息经过序列化之后就需要确定它发往的分区，如果消息 ProducerRecord 中指定了 partition 字段，那么就不需要分区器的作用，因为 partition 代表的就是所要发往的分区号...比如消费者消费完某个分区中的一部分消息时还没有来得及提交消费位移就发生了再均衡操作，之后这个分区又被分配给了消费组内的另一个消费者，原来被消费完的那部分消息又被重新消费一遍，也就是发生了重复消费。...Rebalance 发生的时机有三个： 组成员数量发生变化 订阅主题数量发生变化 订阅主题的分区数发生变化 后两类通常是业务的变动调整所导致的，我们一般不可控制，我们主要说说因为组成员数量变化而引发的...消费者组状态机 重平衡一旦开启，Broker 端的协调者组件就要完成整个重平衡流程，Kafka 设计了一套消费者组状态机（State Machine）来实现。...当有新成员加入或已有成员退出时，消费者组的状态从 Stable 直接跳到 PreparingRebalance 状态，此时，所有现存成员就必须重新申请加入组。
具体来说，如果Kafka集群在一段时间内（这个时间由session.timeout.ms参数配置）没有收到消费者的心跳请求，那么Kafka集群会认为该消费者已经“死亡”，即该消费者与集群的连接已经断开或者消费者进程已经崩溃并将其从消费者组中移除...自动重平衡 当消费者组中的消费者数量发生变化时（如消费者加入、离开或崩溃），Kafka会触发自动重平衡。在重平衡过程中，Kafka会将分区重新分配给存活的消费者，以确保所有分区都有消费者进行消费。...在Kafka中，当消费者尝试消费消息时，它们可能会因为以下原因陷入活锁状态： 处理速度过慢：如果消费者处理消息的速度非常慢，以至于无法及时完成当前任务并开始下一个任务，那么它可能会一直占用着某个分区（partition...当消费者处理消息的时间超过预设的超时时间时，Kafka可以认为该消费者已经死亡，并将其从消费者组中移除，从而触发自动重平衡。...如果消费者调用 poll() 方法的间隔超过了这个时间，那么协调者也会认为消费者已经死亡，并触发重平衡。 这个参数特别有用，因为它确保了消费者不会在处理消息时无限期地阻塞，从而避免了活锁的发生。
GroupMetadataManager：负责管理 GroupMetadata以及消费偏移量的提交，并提供了一系列的组管理的方法供组协调器调用。...，心跳检测正常 Dead：处于该状态的消费组没有任何消费者成员，且元数据信息也已经被删除 Empty：处于该状态的消费组没有任何消费者成员，但元数据信息也没有被删除，知道所有消费者对应的消费偏移量元数据信息过期...DelayedJoin：延迟操作类，用于监视处理所有消费组成员与组协调器之间的心跳超时 GroupConfig：定义了组成员与组协调器之间session超时时间配置 3....在主题发生变化时，比如管理员添加了新的分区，会发生分区重分配。 分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为分区再均衡。...在再均衡期间，消费者无法读取消息，造成整个群组一小段时间的不可用。另外，当分区被重新分配给另一个消费者时，消费者当前的读取状态会丢失，它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。
客户端控制将消息发布到哪个分区。 这可以随机完成，实现一种随机负载平衡，或者可以通过一些语义分区函数来完成。...static membership 静态成员资格旨在提高基于组重新平衡协议构建的流应用程序、消费者组和其他应用程序的可用性。 重新平衡协议依赖组协调器将实体 ID 分配给组成员。...这些生成的 ID 是短暂的，会在成员重新启动和重新加入时发生变化。...对于基于消费者的应用程序，在代码部署、配置更新和定期重启等管理操作期间，这种“动态成员资格”会导致很大一部分任务重新分配给不同的实例。...受此观察启发，Kafka 的组管理协议允许组成员提供持久的实体 ID。 组成员身份基于这些 id 保持不变，因此不会触发重新平衡。
生产者负责选择分配给主题中哪个分区的记录。这可以通过循环方式完成，只是为了平衡负载，或者可以根据一些语义分区功能（例如基于记录中的某些键）来完成。...在Kafka中实现消费的方式是通过在消费者实例上划分日志中的分区，以便每个实例在任何时间点都是分配的“公平份额”的独占消费者。维护组中成员资格的过程由Kafka协议动态处理。...如果新实例加入该组，他们将从该组的其他成员接管一些分区; 如果实例死亡，其分区将分发给其余实例。分区实现了Kafka 的高并发。...这是通过将主题中的分区分配给使用者组中的使用者来实现的，以便每个分区仅由该组中的一个使用者使用。通过这样做，我们确保使用者是该分区的唯一读者并按顺序使用数据。...由于有许多分区，这仍然可以平衡许多消费者实例的负载。但请注意，消费者组中的消费者实例不能超过分区。
.*”，表示订阅所有以test开头的主题，当有新的以test开头的主题被创建时，则需要通过再均衡将该主题的分区分配给消费者。 再均衡的三种触发时机，我们已经清楚了，下面我们看下再均衡是如何实现的。...在Kafka中，每一台Broker上都有一个协调者组件，负责组成员管理、再均衡和提交位移管理等工作。...协调者不仅是负责组成员管理和再均衡，在协调者中还需要负责处理消费者的偏移量提交，而偏移量提交则正是提交到__consumer_offsets的一个分区上。...由于再平衡的开始依赖于心跳的响应，所以heartbeat.interval.ms除了决定心跳的频率，也决定了再均衡的通知频率。...流程 当消费者收到协调者的再均衡开始通知时，需要立即提交偏移量； 消费者在收到提交偏移量成功的响应后，再发送JoinGroup请求，重新申请加入组，请求中会含有订阅的主题信息； 当协调者收到第一个JoinGroup
时间内没有汇报心跳， 那么Kafka就会认为该消费已经dead了 可以看出，消费端的消费者组成员变化一般都是由于异常引起的， 所以其产生的 Rebalance 也是最难控制的。...这样做有诸多弊病，最大的问题在于，消息处理逻辑也是在这个线程中完成的。 因此，一旦消息处理消耗了过长的时间， 心跳请求将无法及时发到协调者那里， 导致协调者“错误地”认为该消费者已“死”。...状态等待分配方案， 当coordinator分配完个消费者消费的分区后， 最后就流转到Stable状态完成重平衡。...当然，后面处理崩溃离组的流程与之前是一样的，我们来看看下面这张图。 ? 组成员崩溃离组场景.jpg 重平衡时协调者对组内成员提交位移的处理。...Coordinator 将该方案以 SyncGroup 的方式将该方案执行下去，通知各个消费者， 这样就完成了一轮 重平衡了。
只能分配给组内的某个 Consumer 实例消费。...当前消费者需要提交的消费位移是offset+1主题有4个分区，消费者组有2个实例，发布应用的时候，会先新启动一个服务节点，加入消费组，通过重平衡分配到到至少1个最多2个分区，消费者的偏移量是 0 还是啥假设...如果消费者超过一定时间没有发送心跳，那么它的会话（Session）就会过期，组协调者会认为该消费者已经宕机，然后触发重平衡。...增加消费者端允许下游系统消费一批消息的最大时长：当消费者组完成重平衡之后，每个消费者实例都会定期地向协调者发送心跳请求，表明它还存活着。...如果某个消费者实例不能及时地发送这些心跳请求，协调者就会认为该消费者已经“死”了，从而将其从组中移除，然后开启新一轮重平衡。
Stable 状态完成重平衡。...这一步的主要目的是让协调者接收分配方案，然后统一以 SyncGroup 响应的方式分发给所有成员，这样组内所有成员就都知道自己该消费哪些分区了。...前面我们已经说到，rebalance 其实就是对 partition 进行重新分配。那么什么时候会发生 rebalance 呢？...而如果现在新增订阅了 B topic，那么 kafka 就需要把 B topic 的 partition 分配给组内的 consumer 进行消费。...因为订阅分区数、以及订阅 topic 数都是我们主动改变才会发生，而组内消费组成员个数发生变化，则是更加随机的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
