网站域名备案证书wordpress修改阅读

1.Kafka的重平衡机制

在集群模式下，一定会涉及到消费者节点数或Broker分区数的变化，如：

1. 消费者加入/离开组（如扩容、宕机）
2. 订阅 Topic 分区变化（如分区数增加）
3. 心跳超时（默认 session.timeout.ms=45s）等

Kafka 的重平衡机制是指在消费者组中新增或删除消费者时，Kafka 集群会重新分配主题分区给各个消费者，以保证每个消费者消费的分区数量尽可能均衡。

重平衡机制的目的是实现消费者的负载均衡和高可用性，以确保每个消费者都能够按照预期的方式消费到消息

虽然kafka没有像RocketMq那样有NameServer的注册中心去维护Broker、消费者、发送者之间的联系，但是它可以通过组织协调器 (Group Coordinator) 管理消费者组的 Broker 节点。

如果它崩渍或者发生故障Kafka 需要重新选举新的 Group Coordinator ，并进行重平衡。

而且当消费者组中的 Leader 消费者崩溃或退出。Kafka 需要选举新的 Leader，重新进行重平衡
一旦触发Rebalance，就会执行以下流程：

• 1.暂停消费:在重平衡开始之前，Kafka 会暂停所有消费者的拉取操作，以确保不会出现重平衡期间的消息丢失或重复消费。
• 2.计算分区分配方案:Kafka 集群会根据当前消费者组的消费者数量和主题分区数量，计算出每个消费者应该分配的分区列表，以实现分区的负载均衡。
• 3.通知消费者:一旦分区分配方案确定，Kafka 集群会将分配方案发送给每个消费者，告诉它们需要消费的分区列表，并请求它们重新加入消费者组。
• 4.重新分配分区:在消费者重新加入消费者组后，Kafka 集群会将分区分配方案应用到实际的分区分配中，重新分配主题分区给各个消费者
• 5.恢复消费: 最后，Kafka 会恢复所有消费者的拉取操作，允许它们消费分配给自己的分

这个很像我们JVM FullGC之后的STW，所以我们尽可能的要避免重平衡时的STW

kafka的设计是遵循分布式原则CAP里的CP（强一致性），通过 组协调器（Group Coordinator） 管理分区分配，确保每个分区仅被一个消费者消费，依赖心跳机制，响应快（但频繁触发可能导致性能抖动）

2.Kafka重平衡优化

默认情况下，消费者离开后会导致重平衡。但如果开启静态成员，Kafka 不会立即移除该消费者，而是等待一段时间 ( group.instance.id )。这样，如果消费者重启，Kafka 仍然保持它的分区分配，不触发重平衡。

还有就是，Kafka 提供了多种分区分配策略，选择合适的策略可以减少重平衡的影响:

• RangeAssignor (默认): 基于 range 分配，可能导致不均衡
  • 按 Topic 分区排序，消费者按字典序排序，平均分配余数优先给前序消费者

例如：Topic "orders" 有5个分区
● 分区排序：P0, P1, P2, P3, P4
消费者名称：["consumer-2", "consumer-1", "consumer-3"]
按字典序排序后：["consumer-1", "consumer-2", "consumer-3"]
按照：先平均分配，余数分配给排序靠前的消费者的逻辑
● 1. 计算基础分配数 = 分区总数 / 消费者数量
● 2. 计算余数 = 分区总数 % 消费者数量
● 3. 前"余数"个消费者多分配1个分区
按照上面的步骤：
● 5/3=1
● 5%3=2
前两个消费多分配1个分区，即：
consumer-1：P0,P1
consumer-2：P2,P3
consumer-3：P4

• RoundRobinAssignor:轮询分配，适用于均匀分布的消费者
  • 所有 Topic 的分区按哈希排序，消费者按字典序排序，轮询分配

分区排序 = [P0, P1, P2, P3, P4]
消费者排序 = [C1, C2, C3]# 轮询顺序：
C1 → P0
C2 → P1
C3 → P2
C1 → P3
C2 → P4

• StickyAssignor: 优先保持之前的分区分配，减少重平衡。
  • 优先保留原有分配结果，仅调整变动部分（减少重平衡时分区迁移）
  • 假如刚开始是：3 消费者 → 5 分区 ，分配策略同 RoundRobin

分区排序 = [P0, P1, P2, P3, P4]
消费者排序 = [C1, C2, C3]# 轮询顺序：
C1 → P0
C2 → P1
C3 → P2
C1 → P3
C2 → P4

新增一个消费者后 C4 时：

• 仅从 C1、C2 各迁移 1 个分区给 C4
• 最小化迁移：C1 保留 P0，C2 保留 P1，C3 保留 P2，C4 获得 P3、P4

分区排序 = [P0, P1, P2, P3, P4]
消费者排序 = [C1, C2, C3,C4]C1 → P0
C2 → P1
C3 → P2
C4 → P3
C4 → P4

• CooperativeStickyAssignor: 渐进式重平衡，不会影响所有消费者，只影响变更的部分
  • 该分配策略只在kafka2.4+生效
  • 初始分配阶段：
    • 消费者组启动时，所有消费者参与分配
    • 使用StickyAssignor算法进行初始分配
    • 每个消费者获得分区分配
    • 开始消费

在具体实践中可以通过：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "order-group");
props.put("partition.assignment.strategy", "org.apache.kafka.clients.consumer.RoundRobinAssignor"); // 指定策略
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

同时在kafka最新发布的4.0版本中(2025-03-19)，提出了下一代消费者重平衡协议，一方面将分区分配逻辑从客户端移到了服务端，简化客户端更加简单，而且这样服务端也能从全局视角更好的处理重平衡。

另外有个比较大的改进，就是允许消费者独立于其他成员进行重平衡了，这就意味着当一个消费者发生变化时，不再需要暂停整个组，其他消费者可以继续正常工作，提高了系统的可靠性和扩展性。

3.RocketMq的重平衡问题

广播模式下，每个消费者都会消费所有消息，不存在重平衡问题。 但是如果实在默认的集群模式下，消费者在一个消费组中，多个消费者会均摊消费，这时候就涉及重平衡的问题。

RocketMQ 的重平衡机制触发条件：

• 消费者加入/退出组。
• Topic 的队列数变化。
• 定时触发：默认每 20 秒检查一次（通过 RebalanceService 线程）。
  • 核心特点：
    • 无全局停顿：消费者通过 本地计算 + 异步拉取 实现渐进式重平衡。
    • 弱一致性：消费者定期从 NameServer 获取元数据，本地计算分配策略（如均分、环形）。
    • 延迟容忍：若消费者宕机，最多需 20 秒触发重平衡（相比 Kafka 的实时响应，延迟更高）。

通过其特点也能看出和Kafka不同的是，RocketMQ他只有个定时重平衡的机制，他有一个重平衡检查线程，会自动的每 20s 进行一次重平衡检查，如果发现有消费者新增或离开时，会触发重新分配队列。

重平衡检查机制核心代码：

    @Overridepublic void run() {log.info(this.getServiceName() + " service started");long realWaitInterval = waitInterval;while (!this.isStopped()) {this.waitForRunning(realWaitInterval);long interval = System.currentTimeMillis() - lastRebalanceTimestamp;if (interval < minInterval) {realWaitInterval = minInterval - interval;} else {boolean balanced = this.mqClientFactory.doRebalance();realWaitInterval = balanced ? waitInterval : minInterval;lastRebalanceTimestamp = System.currentTimeMillis();}}log.info(this.getServiceName() + " service end");}

正是因为RocketMQ 定时进行重平衡的，而不是像 Kafka 依赖心跳机制做实时重平衡a，那么就会出现如果一个消费者宕机，最多需要 20s 才能触发重平衡，导致这段时间内消息堆积在已宕机的消费者上，影响吞吐。不过定时也有个好处就是避免很多网络抖动，或者频繁增加、退出消费者等导致的频繁的重平衡。

但是相比于Kafka，RocketMQ的重平衡机制最大的好处是STW的影响很小

由于 RocketMQ 的消费者是通过 异步拉取然后再放到本地队列处理消息的，即使重平衡发生，每个消费者仍然可以继续消费它当前的队列中的消息，只要重平衡的时间足够短，就可以完全消除STW的发生，因为这段时间本地队列中消息还是在正常处理的。一旦重平衡好了，拉取的时候拉取新的队列的消息就行了。

还有就是RocketMQ 在消费者重平衡时是通过默认就是通过局部调整来完成的。当消费者变化时，只有受影响的消费者会重新分配消息队列，其他消费者不受影响。(类似kafka的渐进式重平衡，但是RocketMQ默认就是这样的)

4.Kafka VS RocketMq

Kafka 配置优化示例：

props.put("partition.assignment.strategy", "org.apache.kafka.clients.consumer.RoundRobinAssignor");
props.put("session.timeout.ms", "60000"); // 增大超时时间，减少误触发
props.put("enable.auto.commit", "false"); // 手动提交 Offset，避免重平衡时重复消费

RocketMQ 配置优化示例：

consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragely());
consumer.setPullBatchSize(32); // 减少拉取频率，降低重平衡压力

5.面试话术

重平衡带来的最大问题就是STW问题，一旦触发重平衡，就会暂停消费，影响吞吐。像Kafka通过协调者监听消费者心跳，能够快速感知消费者的数量变化，进而进行重平衡机制，kafka默认的分区分配策略是基于范围分配，且默认情况下消费者离开后就会触发重平衡，但是如果开启静态成员，那么kafka不会立刻移除该消费者，而是等一段时间，那么其他消费者在就可以正常消费，所以推荐使用StickyAssignor或者渐进式重平衡，不会影响所有消费者而是只影响变更的部分。而RocketMq首先在广播模式下不会有重平衡问题，因为所有的消费者均会消费，但是默认的集群模式下，当消费者组数量发生变化以及Topic的队列数发生变化也会有重平衡问题，rocketMq的消息拉取线程拉到的消息不是直接消费，而是放在ProcessQueue里等待消费者线程去消费，并且有一个定时重平衡线程每20s去检查一次，所以会有20s的缓冲，并结合ProcessQueue，可以很大程度上避免重平衡带来的STW，但是会导致RocketMq反应稍慢，还有就是RocketMq的消费者平衡默认就是通过调整局部来完成的，只有受到影响的消费者会重新分配队列，其他消费者并不受影响，而Kafka需要手动开启，两个方案各有优缺点，像kafka适合实时性要求极高的场景，而RocketMQ适合稳定性要求高的场景。