单Kafka Topic多业务消费场景下Consumer最佳实现方案咨询

Kafka原生支持多消费者组设计，少量（10个以内）消费者组不会带来功能性问题，但若数量过多会产生三类可预见的额外开销：

• 每个消费者组都需要和Kafka broker维持独立的TCP长连接、定期发送心跳检测，会额外占用应用侧和broker侧的CPU、网络资源，量级到几十上百时才会产生明显影响
• 每个消费者组都会独立拉取apiEvents全量消息，若该topic消息体大、TPS高，会产生大量重复的带宽开销
• 每个消费者组的offset都需要独立存储在broker端，只要消费者组数量不超过百级，这部分存储开销可以忽略

可以根据你的业务量级、SLA要求选择以下两种方案：

方案1：单消费者+内部事件总线（推荐TPS<1万/秒的场景使用） #

不需要创建多个消费者组，仅启动1个统一消费者拉取消息，拉取后将消息转发到应用内的事件总线，不同业务逻辑作为独立观察者订阅对应事件即可：

• 全链路仅拉取一次消息，没有重复带宽开销，资源利用率最高
• 所有业务逻辑完全独立实现，不会产生耦合，维护成本极低

以下是Java场景的示例逻辑：

// 自定义事件监听注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface EventListener {
    Class<? extends BaseEvent> value();
}

// 统一消费者仅做消息分发
@KafkaListener(topics = "apiEvents", groupId = "api-events-main-group")
public void consume(ConsumerRecord<String, BaseEvent> record) {
    eventBus.publish(record.value());
}

// 聚合处理逻辑完全独立
@Component
public class EndpointAggregateHandler {
    @EventListener(EndpointUpdateEvent.class)
    public void handle(EndpointUpdateEvent event) {
        // 实现500ms窗口聚合逻辑
    }
}

// DB操作逻辑完全独立
@Component
public class EndpointDbHandler {
    @EventListener(EndpointUpdateEvent.class)
    public void handle(EndpointUpdateEvent event) {
        // 实现单条事件DB写入逻辑
    }
}

若不同业务逻辑的重试、死信策略不同，可以在各个处理器内部单独配置，不需要耦合到统一消费者逻辑中。

方案2：多消费者组（推荐高TPS、不同业务SLA差异大的场景使用） #

如果部分业务逻辑需要独立的消费进度控制、或者某类逻辑消费速度极慢会拖慢其他业务，就可以使用你原本设想的多消费者组方案，仅需要做两点优化：

• 所有消费者组命名统一增加前缀，比如api-events-group-xxx，方便后续运维排查
• 单应用实例内的消费者数量控制在20个以内，超过的话建议拆分到不同实例部署

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