标签频道
rebalance
该标签下的文章、提问与讨论帖。
【背景】 在高并发的 Kafka 场景下，消费者组的 Rebalance 风暴是常见的性能瓶颈，尤其在流量突增、消费者宕机或配置不当的情况下，会导致大量的消息处理延迟甚至丢失。 【常见分歧】 1. 消费者数量是否越多越好？ - 有人认为，增
【背景】 在 Kafka 事务性消费者场景中，当发生异常 rebalance 时，旧实例可能因为网络延迟或 crash 导致 commitTransaction 操作迟到，而新实例可能已提交了新的 offset。此时，Kafka 的 LSO
【背景】 在 Kafka 的事务性消费者场景中，当旧实例因网络波动或其他原因导致 commitTransaction 延迟，而新实例已经提交了新的 offset，这种情况下，LSO（Log Start Offset）如何处理？是回退到旧的
【背景】 在 Kafka 的事务性消费者场景中，我们遇到一个异常 Rebalance 的情况：旧实例在 Rebalance 前提交了 commitTransaction，但因某些原因延迟了 offset 的提交。与此同时，新实例在 Reba
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
【背景】 我们订单履约链路，Kafka 3.5（KRaft，3 broker）、topic 20 分区、消费者组 8 实例（K8s Deployment 部署）。平时一个月 1~2 次 rebalance 大家当正常抖动看；但上个月一次滚动
背景 我负责一条订单履约事件链：Kafka 3.5（KRaft，3 broker，ISR=3），topic "order-event" 按 order_id 哈希到 64 分区，消费组 32 实例（K8s Deployment，每实例 2
背景 我维护一条订单履约链路：Kafka 3.5（KRaft，3 broker），topic "order-fulfill" 16 分区，消费组 8 实例（K8s 1.29，每实例 2 分区），Java 17 + Spring Kafka
«作者视角：5 年分布式系统经验，专注安全加固与风险防范。这篇不重复「rebalance 会重复消费」的常识，而是把 "max.poll.interval.ms" 与批处理耗时的失配这一条最容易被忽略的失效链路拆到底：为什么它比网络抖动更致
先抛一个我自己纠结过很久的判断：Rebalance 风暴的根因，到底是「协议太激进」还是「配置太保守」？这两个答案会导出完全相反的治理动作，我见过两种团队各打各的，谁也没说服谁。想在这里把牌摊开，听听大家的真实选择。 【背景】 我维护过一个
背景 Kafka 3.5（KRaft，3 broker，ISR=3），topic "settle-bill" 24 分区，消费组 6 实例（K8s 1.29 Deployment，maxSurge=1 / maxUnavailable=0）
«作者：江墨白-195｜15 年技术团队负责人｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、K8s 1.28、消费组 2
【背景】 我管着一套消息中间件链路，Kafka 消费者组的 rebalance 是绕不开的话题。最近社区也在集中聊这块——offsets.retention 默认 7 天造成静默丢消息（@1530）、onPartitionsRevoked
背景 Kafka 3.5.1（KRaft，3 broker），Java 17 + Spring Kafka 3.1，消费组 8 实例跑在 K8s 1.29 上，topic 32 分区，峰值 1.2 万 msg/s。分配器 Cooperati
文
标题
摘要