如何控制Apache Kafka消费者选举 实现JMS模式的主备消费逻辑

你遇到的现象是Kafka消费者组默认重平衡逻辑的正常表现：当单Topic单分区的消费者组有新成员加入时，默认的分区分配策略（比如Range、RoundRobin）会重新分配分区，新加入的消费者完全可能被分配到唯一的分区，导致原消费者停止消费，不符合你需要的先启动节点优先为主、故障自动切换的逻辑。以下是可落地的实现方案：

方案1：自定义分区分配策略（原生适配，无额外依赖） #

这是最贴合Kafka原生设计的实现方式，不需要修改服务端逻辑，仅在消费者侧调整即可：

• Kafka的消费者分区分配逻辑支持自定义扩展，你可以继承AbstractPartitionAssignor类，重写assign()方法实现带优先级的分配规则：
  • 给两个消费者预先配置固定优先级权重（比如K-C1权重为2，K-C2权重为1，数值越高优先级越高），可以通过consumer.config的自定义参数或者group.instance.id携带优先级信息
  • 分配分区时，先收集当前消费者组内所有存活实例的优先级，将全部分区分配给优先级最高的存活实例，其余实例不分配任何分区，自然处于待机状态
• 配置方式：消费者启动时将partition.assignment.strategy参数设置为你自定义分配器的全类名即可。
• 该方案完全复用Kafka原生的消费者组存活检测、重平衡触发逻辑，不需要自己实现节点健康检测，稳定性最高。

方案2：上层业务层封装主备判断（改动量小，兼容性强） #

如果不想自定义Kafka内核级逻辑，可以在上层做轻量封装：

• 给两个消费者配置不同的静态标识group.instance.id，同时关闭自动消费逻辑
• 所有消费者启动后，先通过AdminClient查询当前消费者组的存活成员列表，判断当前存活的最高优先级实例（优先级可以按预先约定的规则，比如先启动的节点优先级更高，或者固定K-C1优先级高于K-C2）
• 仅当自身为当前最高优先级存活实例时，才调用poll()拉取消息消费，否则每隔几秒重新查询组内成员状态，待高优先级实例下线后再切换为消费状态
• 配置合理的session.timeout.ms参数，确保主节点故障后，备节点能在你预期的时间范围内感知到切换。

方案3：使用Kafka内置Leader选举能力（高版本适配） #

Kafka 2.8+版本内置了基于Raft的选举能力，提供了KafkaLeaderElection工具类，你可以直接基于该能力实现主备选举：

• 两个消费者启动后都先参与Leader选举，你可以自定义选举规则，优先让先启动的节点当选Leader
• 只有当选为Leader的节点才启动消费逻辑，Follower节点仅监听Leader的存活状态，Leader下线后自动触发重新选举，符合你原有JMS的主备切换逻辑。

注意：不要尝试修改Kafka服务端的Controller选举或者ZooKeeper的选举逻辑，这类改动侵入性极强，会影响集群的所有功能，且升级兼容性极差，不推荐使用。

内容的提问来源于stack exchange，提问作者Mahendran