前言消费者组consumer group是 Kafka 的核心抽象也是“看起来配好了、跑起来不均衡”问题最集中的地方。在 PHP 项目里典型症状有这些起了 10 个消费进程监控上只有两三个在干活其余 CPU 几乎是 0扩了实例数吞吐没涨反而开始出现重复消费日志里反复出现Group coordinator not available、Rebalance in progress某条消息处理了两次业务侧出现重复订单跑了一段时间消费者被踢出组分区转移到别的实例上。这些现象指向同一个事实Kafka 的负载均衡单位是分区partition不是消息。一个分区在同一时刻只能被同组内的一个消费者消费所以组内的最大并行度就等于订阅主题的分区数。只要这个前提没被理解再多的消费者实例也堆不出吞吐而且很多设置还会互相干扰。本文以 PHP 8.5 为运行环境使用ext-rdkafkaphp-rdkafka底层是 librdkafka讲解四件事分区与并行度的关系、分配策略怎么选、max.poll.interval.ms这个最容易被误解的参数、以及一个可运行的消费者脚本。安装扩展前请确认版本对 PHP 8.5 的支持情况以 PECL 页面与该扩展的 README 为准并且扩展版本要与宿主机上的 librdkafka 版本匹配。一、并行度的上限是分区数先把这条规则记牢组内消费者的有效数量 min(消费者实例数, 订阅主题的分区总数)。主题分区数消费者实例数实际结果66每个实例 1 个分区最理想63每个实例 2 个分区6106 个实例各拿 1 个分区剩下的 4 个实例完全空闲15只有 1 个实例工作其余空转且该实例是单线程串行处理所以“加实例不提速”的第一检查项就是看主题有多少分区。查看方式用 Kafka 自带的命令行工具# 每个分区的当前归属与积压情况 kafka-consumer-groups.sh --bootstrap-server kafka:9092 \ --describe --group order-worker输出会逐行列出PARTITION、CURRENT-OFFSET、LOG-END-OFFSET、LAG和CONSUMER-ID。CONSUMER-ID一列是空的或全部指向同一个实例就说明没有均衡LAG持续上涨的那个分区就是瓶颈所在。还有一个比“分区不够”更隐蔽的问题消息键key倾斜。Kafka 默认按 key 的哈希选择分区如果 key 是高基数但流量高度集中比如按商户 ID 分区而头部几个大商户占了大部分消息那么热点分区会拖住整个组其他分区却很闲。这种情况下加分区、加实例都没用要么改 key 的设计要么换分配策略。二、分配策略怎么选消费者组内的分区由组协调者group coordinator分配策略由客户端参数决定策略分配方式特点适用场景range按分区编号连续切片简单但在消费者数不整除时容易不均分区数与消费者数成整数倍时roundrobin逐个轮询分配给消费者数量不整除时更均匀消费者数少于分区数且不整除cooperative-sticky增量式再均衡尽量保留原有归属减少“全体停摆”stop-the-world实例数经常伸缩推荐在 php-rdkafka 里通过Conf设置$conf-set(partition.assignment.strategy, cooperative-sticky);需要注意同组内的所有客户端最好使用互相兼容的策略混用不同策略或新旧客户端时协调者可能无法达成一致表现为反复 rebalance。librdkafka 对于该参数的默认值随版本变化过部署前请以你所安装的 librdkafka 配置文档为准。cooperative-sticky的好处是:实例上下线时不会让所有分区的消费都暂停只把需要迁移的分区收回去再分出去。实例数经常变动弹性伸缩、滚动发布的场景优先选它。php-rdkafka 较新的版本还提供了注册再均衡回调的方法可以在分区被分配/撤销时打印日志是否可用取决于你安装的扩展版本请以扩展的 README 与示例为准。三、最容易被误解的参数max.poll.interval.ms这是 PHP 消费者里“最难查”的一个坑。它的含义是从一次 poll 返回到下一次 poll 之间的最大间隔超过它broker 就认定这个消费者已经死了把它踢出组并触发再均衡。PHP 的消费循环通常是“拉一批 → 逐条处理 → 再拉一批”。如果一批的处理时间写库、调外部接口超过了max.poll.interval.ms就会发生这样的事消费者还在老老实实处理消息broker 认为它挂了把分区转给别的实例处理完提交 offset 时失败或提交到了已经不属于自己的分区新实例从上次提交的位置开始消费——同一批消息被处理了两次之前那个消费者回来继续 poll被告知分区已不在自己名下又触发一轮再均衡。于是监控上就是“反复 rebalance 重复消费”日志里却看不到明显的报错。必须区分两个参数参数管什么由谁发送常见误解session.timeout.ms心跳超时客户端后台线程自动发心跳以为它管业务处理时长max.poll.interval.ms两次 poll 之间的最大间隔你的消费循环不知道它才是处理时长的“紧箍咒”正确的做法是把max.poll.interval.ms设成明显大于最坏情况下一批消息的处理时间同时尽量让每批小一点通过fetch.max.bytes、max.poll.records等参数控制单次拉取量让“一批”的处理时间可预测。四、完整可运行示例下面是一个常驻进程式的消费者脚本PHP 8.5 ext-rdkafka包含手动提交、优雅退出与错误分类php consume.php?php declare(strict_types1); // 运行环境PHP 8.5需 ext-rdkafka $conf new RdKafka\Conf(); $conf-set(bootstrap.servers, getenv(KAFKA_BROKERS) ?: kafka:9092); $conf-set(group.id, getenv(KAFKA_GROUP) ?: order-worker); $conf-set(auto.offset.reset, earliest); // 手动提交处理成功之后再提交避免“消息还没处理完 offset 就提交了” $conf-set(enable.auto.commit, false); // 心跳超时由客户端后台线程负责不需要业务关心 $conf-set(session.timeout.ms, 10000); // 处理时长上限必须大于最坏情况下一批的处理时间 $conf-set(max.poll.interval.ms, 300000); // 增量式再均衡减少实例上下线带来的全体停摆 $conf-set(partition.assignment.strategy, cooperative-sticky); // 控制单次拉取量让每批处理时间可预测 $conf-set(fetch.max.bytes, 1048576); $consumer new RdKafka\KafkaConsumer($conf); $consumer-subscribe([orders]); $running true; if (function_exists(pcntl_async_signals)) { pcntl_async_signals(true); $stop static function () use ($running): void { $running false; }; pcntl_signal(SIGTERM, $stop); pcntl_signal(SIGINT, $stop); } /** 业务处理必须幂等因为至少一次语义下可能重复投递 */ function handle(RdKafka\Message $message): void { $data json_decode((string) $message-payload, true, 512, JSON_THROW_ON_ERROR); printf( 分区%d 偏移%d key%s\n, $message-partition, $message-offset, (string) $message-key ); // 真实项目里此处写库并用业务唯一键做去重如订单号唯一索引 usleep(20000); } $processed 0; while ($running) { $message $consumer-consume(120000); // 单位毫秒 switch ($message-err) { case RD_KAFKA_RESP_ERR_NO_ERROR: try { handle($message); // 处理成功后再提交允许“至多重复一次”但不会丢消息 $consumer-commit($message); $processed; } catch (Throwable $e) { // 处理失败不提交交由重试或死信队列处理 error_log(sprintf( 处理失败 分区%d 偏移%d: %s, $message-partition, $message-offset, $e-getMessage() )); } break; case RD_KAFKA_RESP_ERR__PARTITION_EOF: // 已追平该分区末尾正常现象不是错误 break; case RD_KAFKA_RESP_ERR__TIMED_OUT: // 这个 poll 周期没有新消息继续等待即可 break; default: error_log(消费出错: . $message-errstr()); break; } } // 退出前关闭释放分区让同组其他实例尽快接管 $consumer-close(); printf(已处理 %d 条消息退出\n, $processed);在容器编排里用 Supervisor 或 systemd 常驻这个脚本并给每个副本相同的group.id——这就是 Kafka 意义上的“负载均衡”由协调者把分区分给同组的各个副本。千万不要在 php-fpm 的请求里创建消费者那会导致每次请求都加入一次组、离开一次组触发持续的 rebalance。五、负载均衡的排查顺序遇到不均衡按这个顺序查基本都能定位kafka-consumer-groups.sh --describe看每个分区的CONSUMER-ID与LAG确认是“没分到”还是“分到了但处理慢”数一数主题分区数与实例数确认并行度上限检查 key 的分布确认是否存在热点分区看日志里 rebalance 的频率若是“反复 rebalance”优先查max.poll.interval.ms与处理耗时确认所有实例的group.id一致、订阅的主题列表一致。常见坑点1. 实例数超过分区数❌ 起 20 个消费进程消费只有 4 个分区的主题以为能均摊 ✅ 先扩分区注意 Kafka 只能增加分区不能减少或按分区数规划实例数2. 把session.timeout.ms当成处理超时❌ 处理一条消息要 2 分钟却把session.timeout.ms调大到 5 分钟 ✅ 心跳由客户端后台线程发送限制处理时长的是max.poll.interval.ms3.max.poll.interval.ms小于一批的处理时间❌ 消费者被踢出组、分区转移表现为重复消费 反复 rebalance ✅ 调大该参数或通过fetch.max.bytes/max.poll.records缩小每批4. 开启自动提交❌enable.auto.committrue时消息还没处理完 offset 就被提交进程崩溃即丢消息 ✅enable.auto.commitfalse处理成功后再commit()5. 处理逻辑不幂等❌ 用“至少一次”语义却做非幂等的扣款、发券操作 ✅ 用业务唯一键订单号唯一索引、去重表保证重复投递不会重复生效6. 在 php-fpm 请求中创建消费者❌ 每个请求都subscribe()一次加入组又离开组服务端 rebalance 不断 ✅ 用常驻 CLI 进程Supervisor / systemd / 容器副本运行消费者7. key 设计导致热点分区❌ 按流量高度集中的大客户 ID 做 key单个分区吃掉大部分消息 ✅ 评估 key 分布必要时调整 key 或改用更均匀的分配策略8. 忽略err分类❌ 把RD_KAFKA_RESP_ERR__PARTITION_EOF、__TIMED_OUT当成错误并反复重连 ✅ 用switch ($message-err)区分正常等待、追平末尾与真正的错误总结关注点关键结论落地方式并行度上限等于分区数实例数 ≤ 分区数不够就扩分区分配策略实例频繁伸缩选cooperative-stickypartition.assignment.strategy处理时长由max.poll.interval.ms限制调大它并缩小每批拉取量心跳由session.timeout.ms控制无需业务代码干预提交语义手动提交 幂等处理enable.auto.commitfalse处理后再 commit进程模型常驻进程不用 fpm 请求Supervisor / systemd / 容器副本排查入口--describe看归属与 LAGCONSUMER-ID与LAG两列Kafka 的负载均衡不是客户端“自己分摊”而是协调者按分区派活。因此配置的重点从来不是“怎么调得更均衡”而是三件事让分区数足够、让每个消费者的处理时长可控、让重复投递不会造成业务损失。把这三条处理好组内的负载自然会稳定下来。