解读

在国内高并发 PHP 业务里，分区再均衡（Rebalance）通常指 Kafka 消费组或 Redis Cluster 槽位在节点扩缩容、宕机、网络抖动时，如何把分区/槽位重新分配给存活节点，以保证消费吞吐、数据倾斜和可用性。面试官问“分区再均衡策略”，并不是想听你背 Kafka 源码，而是考察：

1. 是否理解再均衡触发条件（Broker 变更、消费组成员变更、心跳超时、__consumer_offsets 分区 leader 切换等）；
2. 是否知道 PHP 侧如何感知并优雅处理（协程消费、信号量、进程平滑重启、offset 提交策略）；
3. 能否结合业务给出“少抖动、零丢数、低延迟”的落地方案，比如双组订阅、蓝绿消费、流量预热、灰度停写。

知识点

1. Kafka 再均衡协议：RangeAssignor、RoundRobinAssignor、StickyAssignor、CooperativeStickyAssignor 四者差异与适用场景；
2. PHP 消费端实现：rdkafka 扩展（基于 librdkafka）的 rebalance_cb 回调、assign/unassign 时机、consumer->close() 与 SIGTERM 信号捕捉；
3. 再均衡风暴：Coordinator 缓存、session.timeout.ms、max.poll.interval.ms、heartbeat.interval.ms 参数调优；
4. 业务层幂等：MySQL 唯一索引、Redis SETNX、悲观锁、乐观锁、本地消息表，防止重复消费；
5. 国内云厂商差异：阿里云 Kafka 的“自由组 rebalance 抑制”开关、腾讯云 CKafka 的“静态成员”功能、华为云“重平衡观测”指标；
6. PHP-FPM 模式下长连接陷阱：再均衡触发后旧连接仍持有无效 fd，需用 CLI 常驻进程或 Swoole/ReactPHP 协程消费；
7. 监控告警：Prometheus + Grafana 监控 consumer lag、rebalance frequency、partition ownership 变化速率；钉钉/飞书机器人 30s 内三次 rebalance 直接电话告警。

答案

“分区再均衡策略”我拆成三步：事前、事中、事后。

事前：

1. 选用 StickyAssignor+Cooperative 协议，让 PHP 消费组在扩容时尽量保持原有分区归属，减少全量重排；
2. 把 session.timeout.ms 调到 30s，heartbeat.interval.ms 10s，max.poll.interval.ms 5min，给 GC 或网络抖动留 buffer；
3. 上线前做“灰度双组”：旧组继续跑，新组用不同的 group.id 订阅同一 topic，通过监控 lag 曲线确认无抖动后，再切换 DNS 或配置中心，实现蓝绿消费。

事中：

1. PHP 端用 rdkafka 的 rebalance_cb 注册回调，在 RD_KAFKA_RESP_ERR__ASSIGN_PARTITIONS 阶段先暂停业务协程，清空本地内存队列，确保没有“飞包”；
2. 采用“手动异步提交 + 本地消息表”双保险：每 3s 批量 commitSync，同时把最新 offset 写入本地 Redis 的 Hash，进程重启时先读 Redis 再 seek，保证至少一次语义；
3. 如果检测到 rebalance frequency 连续 2 次在 1min 内触发，立即触发熔断：把消费进程数缩容到 1，降低 Coordinator 压力，同时告警值班。

事后：

1. 再均衡结束后，用 kafka-consumer-groups.sh 验证每个分区当前 offset 与业务库最大主键是否对齐，若差值>1000 条，触发补偿任务；
2. 补偿任务用 PHP CLI 脚本，按主键区间分段扫描，把漏数据通过幂等接口重新写回，完成后发送钉钉卡片；
3. 把本次 rebalance 的日志（Coordinator 节点、leader 变更时间、分区迁移序列）落盘到 ELK，周会做复盘，沉淀为“再均衡 SOP”，下次扩容直接按 SOP 执行，10min 内完成无损再均衡。

拓展思考

1. 如果业务用 Redis Cluster 而不是 Kafka，槽位再均衡（reshard）期间 PHP 如何防止“ASK/MOVED”风暴？能否提前用 redis-trib 把热点 key 手动拆槽，再配合本地缓存 Slot 映射表？
2. 在 Serverless 场景（如阿里云 SAE 弹性伸缩），PHP 函数实例生命周期只有 5min，如何设计“静态成员”机制，让函数实例在冷启动时复用旧 member.id，避免频繁 rebalance？
3. 当再均衡导致消息乱序（如订单创建与支付两个分区被分配到不同 PHP 进程），如何用“分区键 + 重试队列 + 状态机”保证最终一致性，而不是简单加全局锁？
4. 如果公司预算有限，不能上三中心 Kafka，只能单机房 + 跨可用区，如何在 PHP 侧实现“半同步写双 Topic”方案，实现机房级容灾，同时把 rebalance 限制在单 AZ 内，减少跨区网络抖动影响？
5. 未来升级到 Pulsar 的 Shared 订阅模式后，PHP 通过 websocket 消费，是否还需要传统意义的 rebalance？如果不需要，如何重新设计幂等与顺序语义？