在日常使用 Kafka 做消息队列开发时很多小伙伴都会遇到一个经典疑问为什么有时候一条消息只能被一个消费者处理有时候却能被多个消费者同时消费其实答案的核心就在于Kafka 消费者组groupId以及底层的分区分配机制。本文结合实战代码案例拆解 Kafka 两种主流消费模式队列模式负载均衡/削峰、发布订阅模式消息分发同时对比两者使用场景、代码写法与底层原理帮大家彻底吃透消费者组机制。一、业务场景引入我们先通过两个真实业务场景直观感受两种消费模式的区别1.场景1流量削峰、任务分摊接口接收大量用户请求后端有多个服务实例共同处理任务。要求一条请求只被一台服务处理避免重复执行业务同时分摊流量压力防止单服务被打垮。2.场景2消息分发、多业务联动订单创建成功后需要同步完成加积分、发短信、数据统计三个独立业务。要求一条订单消息被三个不同业务服务同时消费各司其职。这两个场景正好对应 Kafka 基于消费者组实现的两种消费模型。二、基础代码环境说明本文案例基于SpringBoot Spring-Kafka实现分为消息生产者和消息消费者两部分所有案例共用同一个 Kafka 主题tp-mq-dispatch。2.1 统一生产者代码生产者职责很简单接收前端请求将消息发送到指定 Kafka 主题不处理任何耗时业务保证接口快速响应。RestControllerpublic class KafkaProducerController {Autowiredprivate KafkaTemplateString, String kafkaTemplate;PostMapping(value /dispatch_with_mq, consumes application/json; charsetutf-8)public ResponseEntityString dispatchWithMQ(RequestBody IncrCountReq data) {String msg to the moon!;// 消息发送至主题 tp-mq-dispatchkafkaTemplate.send(tp-mq-dispatch, msg);return ResponseEntity.ok(消息发送成功);}}核心逻辑接口接收请求 → 发送消息到 Kafka → 直接返回结果实现业务解耦。三、模式一同消费者组 → 队列模式负载均衡/削峰填谷3.1 核心原理Kafka 的主题由多个分区Partition组成消息分布在不同的分区中。当多个消费者属于同一个groupId消费者组时Kafka 会采用队列Queuing模式- 组内消费者会按分区进行分配一个分区同一时间只能被组内一个消费者占用- 因为一条消息只会写入某一个分区所以这条消息就只会被持有该分区的那个消费者处理组内绝不会出现多个消费者重复消费同一消息- 组内消费者各自负责不同分区天然实现流量分摊不需要在消息层面争抢- Kafka 为整个消费者组维护一份消费偏移量offset记录每个分区消费到的位置。该模式最常用场景流量削峰、异步任务处理、集群服务分摊压力。3.2 实战代码实现方式1单监听 并发线程推荐通过concurrency参数指定组内消费者线程数这些线程同属一个消费者组Kafka 会为它们分配不同的分区代码简洁生产环境高频使用。Componentpublic class BalanceConsumer {// 所有消费线程属于同一个消费者组 TEST_GROUPKafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP, concurrency 3)public void consume(String msg) {System.out.println(负载均衡消费者收到消息 msg);// 执行业务逻辑countService.incrManyTimes(10000);}}参数说明-groupId TEST_GROUP统一消费者组-concurrency 3在当前实例中启动 3 个消费者线程等效于 3 个同组消费者。⚡ 关键注意要让这 3 个线程都真正工作主题 tp-mq-dispatch 的分区数至少为 3。若分区数为 1则只有 1 个线程能消费其余空闲。增加消费者线程前务必检查分区数量。方式2多个监听方法 同一组ID编写多个KafkaListener监听同一个主题、同一个groupId效果和上面一致它们会被分配到不同分区消息依然只被其中一个处理。Componentpublic class BalanceConsumer {KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer1(String msg) {System.out.println(消费者1 处理消息 msg);}KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer2(String msg) {System.out.println(消费者2 处理消息 msg);}KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer3(String msg) {System.out.println(消费者3 处理消息 msg);}}3.3 运行效果生产者连续发送多条消息这些消息会落入不同分区3个消费者/线程各自处理自己负责分区的消息同一条消息只会被其中一个消费者处理完美实现流量分摊、削峰填谷。四、模式二不同消费者组 → 发布订阅模式消息分发/多业务处理4.1 核心原理当多个消费者监听同一个主题但分属不同groupId消费者组时Kafka 会采用发布订阅Pub/Sub模式- Kafka为每一个消费者组单独维护一份消费偏移量offset组与组之间消费进度互不干扰- 每个组独立地对主题的所有分区进行分配和消费相当于各自拥有主题的完整消息视图- 生产者发送一条消息所有不同组的消费者都会完整收到这条消息通过各自组内负责该分区的消费者该模式最常用场景订单联动、消息通知、数据同步、多模块业务解耦。4.2 实战代码实现三个监听方法监听同一个主题但配置完全不同的groupId模拟三个独立的业务服务。Componentpublic class PubSubConsumer {// 消费者组1积分服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP1)public void svr1(String msg) {System.out.println(积分服务 收到消息 msg);// 执行加积分逻辑}// 消费者组2短信通知服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP2)public void svr2(String msg) {System.out.println(短信服务 收到消息 msg);// 执行发短信逻辑}// 消费者组3数据分析服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP3)public void svr3(String msg) {System.out.println(数据分析服务 收到消息 msg);// 执行数据统计逻辑}}4.3 运行效果生产者发送一条消息TEST_GROUP1、TEST_GROUP2、TEST_GROUP3三个分组的消费者全部接收到该消息各自执行自身业务实现一条消息驱动多个业务流程。五、两种模式全面对比为了方便大家记忆整理核心对比表格消费模式消费者组配置消息消费规则底层机制典型业务场景队列模式负载均衡所有消费者同一个 groupId一条消息仅被组内一个消费者处理分区分配给组内消费者每条消息只属于一个分区异步任务、高并发接口解耦、服务集群负载分担发布订阅模式消息分发消费者使用不同 groupId一条消息被所有分组的消费者处理每个组独立分配全部分区互不干扰订单通知、多端推送、数据同步、日志收集生活化举例理解1.队列模式同组银行有 3 个柜台窗口分区3 个柜员同组消费者每人固定负责一个窗口客户随机被叫号到不同窗口一个客户只由对应窗口的柜员接待分担工作压力。2.发布订阅模式不同组老板发布一条全员通知销售组、财务组、技术组不同组全部收到通知各部门处理对应工作。六、常见误区纠正误区1一条消息被消费后其他消费者一定收不到错误。这个结论仅适用于同一个消费者组。不同消费者组之间相互独立消费进度互不影响消息可以被所有分组重复消费。误区2想要多实例分担压力就要写多个不同 groupId 的监听错误。多实例负载均衡必须保证所有实例使用同一个 groupId如果分组不同会变成消息广播造成业务重复执行。误区3同组消费者是在争抢消息谁快谁消费错误。同组消费者是按分区分配每个消费者固定消费负责分区的消息不存在“抢”的过程。真正的并行度受分区数限制多出来的消费者会空闲。七、生产环境落地建议1.流量削峰/异步任务统一使用同一个消费者组配合concurrency参数或多服务实例部署实现负载均衡。务必保证主题分区数 ≥ 总消费者线程数避免消费者闲置。2.多业务消息分发不同业务服务配置独立的消费者组监听同一个主题利用发布订阅模式实现业务解耦新增业务只需新增一个消费者组即可无需改动原有代码。3.分组命名规范生产环境建议按业务线/服务名命名groupId例如order_group、sms_group便于问题排查和运维管理。4.偏移量注意事项每个消费者组独立维护 offset删除/修改分组不会影响其他分组的消费进度运维时无需担心全局消息丢失。八、总结1. Kafka 消费行为由消费者组groupId和底层的分区分配共同决定这是核心关键点2.同组消费 队列模式分区分配使消息分摊主打负载均衡、削峰填谷3.异组消费 发布订阅模式各组独立消费全部分区实现消息广播、多业务分发4. 开发时根据业务需求选择分组策略并合理设置分区数量就能精准控制消息的消费逻辑避开重复消费、流量不均等问题。掌握消费者组机制才算真正入门 Kafka 消息模型后续再学习分区、重平衡等高级特性也会更加轻松。
在日常使用 Kafka 做消息队列开发时很多小伙伴都会遇到一个经典疑问为什么有时候一条消息只能被一个消费者处理有时候却能被多个消费者同时消费其实答案的核心就在于Kafka 消费者组groupId以及底层的分区分配机制。本文结合实战代码案例拆解 Kafka 两种主流消费模式队列模式负载均衡/削峰、发布订阅模式消息分发同时对比两者使用场景、代码写法与底层原理帮大家彻底吃透消费者组机制。一、业务场景引入我们先通过两个真实业务场景直观感受两种消费模式的区别1.场景1流量削峰、任务分摊接口接收大量用户请求后端有多个服务实例共同处理任务。要求一条请求只被一台服务处理避免重复执行业务同时分摊流量压力防止单服务被打垮。2.场景2消息分发、多业务联动订单创建成功后需要同步完成加积分、发短信、数据统计三个独立业务。要求一条订单消息被三个不同业务服务同时消费各司其职。这两个场景正好对应 Kafka 基于消费者组实现的两种消费模型。二、基础代码环境说明本文案例基于SpringBoot Spring-Kafka实现分为消息生产者和消息消费者两部分所有案例共用同一个 Kafka 主题tp-mq-dispatch。2.1 统一生产者代码生产者职责很简单接收前端请求将消息发送到指定 Kafka 主题不处理任何耗时业务保证接口快速响应。RestControllerpublic class KafkaProducerController {Autowiredprivate KafkaTemplateString, String kafkaTemplate;PostMapping(value /dispatch_with_mq, consumes application/json; charsetutf-8)public ResponseEntityString dispatchWithMQ(RequestBody IncrCountReq data) {String msg to the moon!;// 消息发送至主题 tp-mq-dispatchkafkaTemplate.send(tp-mq-dispatch, msg);return ResponseEntity.ok(消息发送成功);}}核心逻辑接口接收请求 → 发送消息到 Kafka → 直接返回结果实现业务解耦。三、模式一同消费者组 → 队列模式负载均衡/削峰填谷3.1 核心原理Kafka 的主题由多个分区Partition组成消息分布在不同的分区中。当多个消费者属于同一个groupId消费者组时Kafka 会采用队列Queuing模式- 组内消费者会按分区进行分配一个分区同一时间只能被组内一个消费者占用- 因为一条消息只会写入某一个分区所以这条消息就只会被持有该分区的那个消费者处理组内绝不会出现多个消费者重复消费同一消息- 组内消费者各自负责不同分区天然实现流量分摊不需要在消息层面争抢- Kafka 为整个消费者组维护一份消费偏移量offset记录每个分区消费到的位置。该模式最常用场景流量削峰、异步任务处理、集群服务分摊压力。3.2 实战代码实现方式1单监听 并发线程推荐通过concurrency参数指定组内消费者线程数这些线程同属一个消费者组Kafka 会为它们分配不同的分区代码简洁生产环境高频使用。Componentpublic class BalanceConsumer {// 所有消费线程属于同一个消费者组 TEST_GROUPKafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP, concurrency 3)public void consume(String msg) {System.out.println(负载均衡消费者收到消息 msg);// 执行业务逻辑countService.incrManyTimes(10000);}}参数说明-groupId TEST_GROUP统一消费者组-concurrency 3在当前实例中启动 3 个消费者线程等效于 3 个同组消费者。⚡ 关键注意要让这 3 个线程都真正工作主题 tp-mq-dispatch 的分区数至少为 3。若分区数为 1则只有 1 个线程能消费其余空闲。增加消费者线程前务必检查分区数量。方式2多个监听方法 同一组ID编写多个KafkaListener监听同一个主题、同一个groupId效果和上面一致它们会被分配到不同分区消息依然只被其中一个处理。Componentpublic class BalanceConsumer {KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer1(String msg) {System.out.println(消费者1 处理消息 msg);}KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer2(String msg) {System.out.println(消费者2 处理消息 msg);}KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP)public void consumer3(String msg) {System.out.println(消费者3 处理消息 msg);}}3.3 运行效果生产者连续发送多条消息这些消息会落入不同分区3个消费者/线程各自处理自己负责分区的消息同一条消息只会被其中一个消费者处理完美实现流量分摊、削峰填谷。四、模式二不同消费者组 → 发布订阅模式消息分发/多业务处理4.1 核心原理当多个消费者监听同一个主题但分属不同groupId消费者组时Kafka 会采用发布订阅Pub/Sub模式- Kafka为每一个消费者组单独维护一份消费偏移量offset组与组之间消费进度互不干扰- 每个组独立地对主题的所有分区进行分配和消费相当于各自拥有主题的完整消息视图- 生产者发送一条消息所有不同组的消费者都会完整收到这条消息通过各自组内负责该分区的消费者该模式最常用场景订单联动、消息通知、数据同步、多模块业务解耦。4.2 实战代码实现三个监听方法监听同一个主题但配置完全不同的groupId模拟三个独立的业务服务。Componentpublic class PubSubConsumer {// 消费者组1积分服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP1)public void svr1(String msg) {System.out.println(积分服务 收到消息 msg);// 执行加积分逻辑}// 消费者组2短信通知服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP2)public void svr2(String msg) {System.out.println(短信服务 收到消息 msg);// 执行发短信逻辑}// 消费者组3数据分析服务KafkaListener(topics tp-mq-dispatch, groupId TEST_GROUP3)public void svr3(String msg) {System.out.println(数据分析服务 收到消息 msg);// 执行数据统计逻辑}}4.3 运行效果生产者发送一条消息TEST_GROUP1、TEST_GROUP2、TEST_GROUP3三个分组的消费者全部接收到该消息各自执行自身业务实现一条消息驱动多个业务流程。五、两种模式全面对比为了方便大家记忆整理核心对比表格消费模式消费者组配置消息消费规则底层机制典型业务场景队列模式负载均衡所有消费者同一个 groupId一条消息仅被组内一个消费者处理分区分配给组内消费者每条消息只属于一个分区异步任务、高并发接口解耦、服务集群负载分担发布订阅模式消息分发消费者使用不同 groupId一条消息被所有分组的消费者处理每个组独立分配全部分区互不干扰订单通知、多端推送、数据同步、日志收集生活化举例理解1.队列模式同组银行有 3 个柜台窗口分区3 个柜员同组消费者每人固定负责一个窗口客户随机被叫号到不同窗口一个客户只由对应窗口的柜员接待分担工作压力。2.发布订阅模式不同组老板发布一条全员通知销售组、财务组、技术组不同组全部收到通知各部门处理对应工作。六、常见误区纠正误区1一条消息被消费后其他消费者一定收不到错误。这个结论仅适用于同一个消费者组。不同消费者组之间相互独立消费进度互不影响消息可以被所有分组重复消费。误区2想要多实例分担压力就要写多个不同 groupId 的监听错误。多实例负载均衡必须保证所有实例使用同一个 groupId如果分组不同会变成消息广播造成业务重复执行。误区3同组消费者是在争抢消息谁快谁消费错误。同组消费者是按分区分配每个消费者固定消费负责分区的消息不存在“抢”的过程。真正的并行度受分区数限制多出来的消费者会空闲。七、生产环境落地建议1.流量削峰/异步任务统一使用同一个消费者组配合concurrency参数或多服务实例部署实现负载均衡。务必保证主题分区数 ≥ 总消费者线程数避免消费者闲置。2.多业务消息分发不同业务服务配置独立的消费者组监听同一个主题利用发布订阅模式实现业务解耦新增业务只需新增一个消费者组即可无需改动原有代码。3.分组命名规范生产环境建议按业务线/服务名命名groupId例如order_group、sms_group便于问题排查和运维管理。4.偏移量注意事项每个消费者组独立维护 offset删除/修改分组不会影响其他分组的消费进度运维时无需担心全局消息丢失。八、总结1. Kafka 消费行为由消费者组groupId和底层的分区分配共同决定这是核心关键点2.同组消费 队列模式分区分配使消息分摊主打负载均衡、削峰填谷3.异组消费 发布订阅模式各组独立消费全部分区实现消息广播、多业务分发4. 开发时根据业务需求选择分组策略并合理设置分区数量就能精准控制消息的消费逻辑避开重复消费、流量不均等问题。掌握消费者组机制才算真正入门 Kafka 消息模型后续再学习分区、重平衡等高级特性也会更加轻松。
` 派生宏的合法目标类型约束)
