📚 课程目录第2章 Kafka消费者基础

2. Kafka 消费者基础：消费者组、分区分配与偏移量提交

在 Kafka 消费体系中，消费者组（Consumer Group） 是水平扩展与故障容错的核心抽象。理解消费者组的工作机制、分区分配策略以及偏移量提交方式，是排查消费停滞、重复消费、分区倾斜等故障的前提。本节从这三个维度展开，为后续压测与故障注入打下理论基础。

2.1 消费者组概念与核心特性

消费者组由一个 Group ID 标识，组内多个消费者实例共同订阅一个或多个主题，每个分区只能被组内的一个消费者实例消费。这种“一对多”的映射关系保证了消息的顺序性与负载均衡。

特性	说明
分区独占性	同一分区在同一时刻只能被组内一个消费者消费，保证分区内消息有序。
水平伸缩	增加消费者实例可提升消费吞吐，但消费者数不应超过分区总数，否则多余消费者闲置。
故障重平衡	消费者加入/离开或分区数变更时触发 Rebalance，重新分配分区归属。
偏移量隔离	每个消费者组独立维护每个分区的消费偏移量（Offset），互不干扰。

故障排查要点： 当消费者组内实例数超过分区数时，多余实例将永远无法分配到分区，表现为“空转”或“无消息消费”。压测前应确保分区数 ≥ 消费者数。

2.2 分区分配策略

当消费者组触发 Rebalance 时，Kafka 使用分区分配策略决定每个消费者负责哪些分区。Go 客户端（如 sarama、confluent-kafka-go）支持三种内置策略：Range、RoundRobin、Sticky。选择不当会导致分区分配不均，进而引发部分消费者过载、部分闲置。

策略	分配逻辑	优点	缺点
Range	按主题分区排序后，依次分配给消费者；每个主题独立分配。	实现简单，同一主题分区尽量集中。	多主题时容易产生严重倾斜，部分消费者分配过多分区。
RoundRobin	所有订阅主题的分区统一排序后轮询分配给消费者。	分区数接近时分配均匀。	Rebalance 时可能全量重分配，影响较大。
Sticky	在保持均匀分配的前提下，尽量保留上一次的分配结果。	Rebalance 时变动最小，减少重复消费。	实现复杂，极端场景下仍可能倾斜。

压测故障场景： 使用 Range 策略且订阅多个分区数不同的主题时，消费者 1 可能承担 80% 的分区，而消费者 2 仅承担 20%。压测中该消费者 1 的 CPU/内存率先打满，导致消费延迟飙升。建议生产环境优先使用 Sticky 策略。

2.3 偏移量提交机制

偏移量（Offset）是消费者在分区中的消费位置标记。Kafka 通过 __consumer_offsets 内部主题存储每个消费者组在每个分区上的偏移量。提交方式分为 自动提交 和 手动提交，选择不当是导致“重复消费”或“消息丢失”的常见根源。

2.3.1 自动提交 vs 手动提交

提交方式	触发时机	风险	适用场景
自动提交	定时（默认 5s）或 poll() 返回时自动提交已拉取的最大偏移量。	消费者崩溃时可能重复消费大量消息；处理耗时超过提交间隔时偏移量可能超前。	允许少量重复、处理逻辑幂等的场景。
手动提交（同步）	业务处理完成后主动调用 `commitSync()`。	阻塞当前线程，吞吐下降；重试机制不完善时可能阻塞整个消费循环。	对重复敏感、处理逻辑较短的场景。
手动提交（异步）	业务处理完成后调用 `commitAsync()`，不阻塞。	提交失败时无重试，可能导致偏移量回退，引发重复消费。	高吞吐场景，配合回调处理提交失败。

2.3.2 Go 客户端偏移量提交示例

以下代码展示使用 sarama 客户端进行手动同步提交的典型模式：

package main

import (
    "fmt"
    "log"
    "os"
    "os/signal"
    "time"

    "github.com/IBM/sarama"
)

func main() {
    config := sarama.NewConfig()
    config.Consumer.Group = "my-group"
    config.Consumer.Offsets.Initial = sarama.OffsetOldest
    // 关闭自动提交
    config.Consumer.Offsets.AutoCommit.Enable = false

    client, err := sarama.NewConsumerGroup([]string{"localhost:9092"}, "my-group", config)
    if err != nil {
        log.Fatal(err)
    }
    defer client.Close()

    handler := &ConsumerGroupHandler{}
    sig := make(chan os.Signal, 1)
    signal.Notify(sig, os.Interrupt)

    go func() {
        for {
            if err := client.Consume(nil, []string{"topic-a"}, handler); err != nil {
                log.Fatal(err)
            }
        }
    }()

    <-sig
    fmt.Println("Shutting down...")
}

type ConsumerGroupHandler struct{}

func (h *ConsumerGroupHandler) Setup(sarama.ConsumerGroupSession) error   { return nil }
func (h *ConsumerGroupHandler) Cleanup(sarama.ConsumerGroupSession) error { return nil }

func (h *ConsumerGroupHandler) ConsumeClaim(session sarama.ConsumerGroupSession, claim sarama.ConsumerGroupClaim) error {
    for msg := range claim.Messages() {
        fmt.Printf("Partition:%d Offset:%d Key:%s Value:%s\n",
            msg.Partition, msg.Offset, string(msg.Key), string(msg.Value))

        // 模拟业务处理耗时
        time.Sleep(50 * time.Millisecond)

        // 手动同步提交当前偏移量
        session.MarkMessage(msg, "")
        session.Commit()
    }
    return nil
}

  压测故障排查提示： 在 Go 压测场景中，如果使用自动提交且处理耗时波动较大（如 10ms ~ 500ms），偏移量提交可能滞后于实际处理进度。当消费者 Rebalance 或崩溃时，未提交的偏移量会导致大量消息被重复消费。建议压测时开启手动提交，并在 Commit() 前后记录耗时，作为排查消费延迟的辅助指标。

2.4 偏移量提交与 Rebalance 的交互

Rebalance 发生时，消费者组会暂停所有消费，等待分区重新分配。如果偏移量提交不及时，Rebalance 后新消费者可能从更早的偏移量开始消费，造成重复。以下是关键交互流程：

正常消费阶段：消费者不断拉取消息、处理、提交偏移量。
触发 Rebalance：消费者加入/离开或分区数变更，协调器（Coordinator）发起 Rebalance。
暂停消费：所有消费者停止拉取，等待分配结果。
偏移量提交：消费者在 Rebalance 前应提交已处理消息的偏移量（由客户端策略决定）。
重新分配：协调器根据分配策略将分区分配给消费者。
恢复消费：消费者从提交的偏移量继续消费。

故障场景： 如果消费者在处理大量消息后尚未提交偏移量就发生崩溃，Rebalance 后新消费者将从上次提交点重新消费，导致大量重复。压测中应模拟“处理中崩溃”场景，验证业务幂等性是否完备。

2.5 本章小结

消费者组 是 Kafka 消费水平扩展与故障容错的基本单位，分区独占性保证了分区内有序。
分区分配策略 直接影响负载均衡效果，生产环境优先选择 Sticky 策略以减少 Rebalance 影响。
偏移量提交 是保证“至少一次”语义的关键，手动提交（同步/异步）比自动提交更可控，但需注意性能与重试逻辑。
在 Go 压测闭环中，应重点监控 分区分配均匀度 和 偏移量提交延迟，这两项指标直接关联消费稳定性。