在 RocketMQ 中，集群消费（Clustering）和广播消费（Broadcasting）是两种最核心的消费模式。它们的本质区别在于：同一条消息在同一个消费者组（ConsumerGroup）内的分发逻辑和消费进度（Offset）管理机制不同。

简单用一句话概括：

• 集群消费：“分工合作”，一条消息只能被组内一个消费者处理。
• 广播消费：“全员广播”，一条消息会被组内所有消费者各处理一次。

以下是它们本质区别的深度剖析：

1. 消息分发逻辑（核心区别）

• 集群消费 (Clustering - 默认模式)

  • 机制：同一个 ConsumerGroup 下的多个消费者实例共同均摊消费该 Topic 下的消息。RocketMQ 会通过负载均衡机制，将 Message Queue 分配给组内的消费者。
  • 比喻：相当于“团队分工”。100个快递（消息）交给包含10个快递员的站点（消费者组），每个快递员平均送10个，同一个快递不会被两个人重复派送。
  • 适用场景：绝大多数微服务解耦场景，如订单处理、扣减库存、短信发送等（避免重复执行任务）。

• 广播消费 (Broadcasting)

  • 机制：同一个 ConsumerGroup 下的每一个消费者实例都会收到该 Topic 下的所有消息。各个消费者独立消费，互不干扰，没有负载均衡的概念。
  • 比喻：相当于“大喇叭广播”。村长用广播通知“明天开会”（消息），全村100个人（消费者组）每个人都能完整听到这条通知。
  • 适用场景：多节点状态同步。例如：刷新各个微服务节点内存中的本地缓存、分布式配置中心的配置变更下发等。

2. 消费进度（Offset）存储机制（技术实现的本质区别）

• 集群消费

  • 存储位置：Broker 端（服务端）。
  • 原因：因为整个组共同消费一个 Topic，消费进度是属于整个“组”的。如果 Consumer A 挂机了，它负责的队列会被分配给 Consumer B，Consumer B 需要向 Broker 询问：“刚才 A 消费到哪了？”，然后继续消费。
  • 可靠性：非常高。消费者重启或宕机，不会导致消息大量丢失或重复。

• 广播消费

  • 存储位置：Consumer 端（客户端本地，默认存在用户的家目录下，如 ~/.rocketmq_offsets）。
  • 原因：每个消费者完全独立，A 消费到哪里跟 B 毫无关系，Broker 没必要（也承受不了）去记录每一个具体消费者实例的进度。
  • 可靠性：较低。如果消费者宕机，在离线期间产生的消息，等它重启后可能会丢失（因为本地 offset 没有更新，重启后默认从最新位置开始消费）。

3. 容错与重试机制

• 集群消费

  • 失败重试：支持。如果某条消息消费失败，RocketMQ 会自动将其投递到重试队列（Retry Queue），并根据延迟级别多次重试。
  • 死信队列：支持。如果重试了 16 次依然失败，消息会进入死信队列（DLQ），等待人工干预。

• 广播消费

  • 失败重试：不支持。在广播模式下，如果消费失败，RocketMQ 不管，消息直接丢弃（“Fire and Forget”）。如果需要重试，必须由业务代码自己在本地实现。
  • 死信队列：不支持。

4. 总结与对比表格

总结：
选择哪种模式，核心看你的业务逻辑是需要“一份数据只被处理一次”（选集群），还是需要“一份数据让所有节点都知道”（选广播）。在实际开发中，95% 以上的场景使用的是集群消费。