rocketmq默认集群消费，广播消费需显式开启；集群模式下消息仅被同组一个消费者处理，支持重试与进度统一管理；广播模式下每条消息被组内所有消费者各消费一次，进度本地存储且不支持重试。
RocketMQ 默认采用集群消费模式，广播消费需显式开启。选错模式会导致消息重复、漏消费或无法重试等严重问题，关键在于明确“一条消息是否必须被所有实例处理”。
集群消费（CLUSTERING）：消息只被组内一个消费者处理
同一 Consumer Group 下的多个消费者共同分担 Topic 的全部消息，每条消息仅由其中一台实例消费。Broker 会将 Topic 下的 MessageQueue 均匀分配给各消费者，实现负载均衡与故障转移。
- 消费进度（Offset）由 Broker 统一维护，支持重试、死信、位点重置和堆积监控
- 适合订单处理、日志归集、任务分发等“只需处理一次”的场景
- 代码中无需额外设置，默认即为集群模式：consumer.setMessageModel(MessageModel.CLUSTERING)
- 消费者宕机后，其负责的队列会自动重新分配给其他存活实例
广播消费（BROADCASTING）：每条消息被组内所有消费者各消费一次
同一 Consumer Group 内每个消费者都会收到全量消息，彼此独立消费、互不感知。消费进度不共享，各自保存在本地磁盘文件中。
- 不支持消息重试、死信、服务端位点管理及堆积告警
- 适合配置推送、本地缓存刷新、状态同步等“每个节点都必须响应”的场景
- 需手动启用：properties.put(PropertyKeyConst.MessageModel, PropertyValueConst.BROADCASTING)
- 注意：5.x gRPC SDK 已移除广播模式支持，如需使用应改用 Remoting SDK 或为每个实例分配独立 Group ID
核心差异一目了然
集群消费是点对点（P2P），强调消息唯一性与可靠性；广播消费本质是发布/订阅（Pub/Sub），强调通知可达性与本地自治性。二者在消费语义、进度存储、容错能力上存在根本区别：
- 消息可见性：集群下消息仅投递一次；广播下每条消息复制多份，分别送达每个实例
- Offset 管理：集群依赖 Broker 存储；广播完全本地化，重启可能从最新位点开始消费
- 扩展性影响：集群可水平扩容消费者提升吞吐；广播下增加实例不降低单机压力，反而加重整体负载
- 顺序保障：两者均支持分区有序，但广播模式下全局顺序无法保证，因各实例处理节奏不同
怎么选？看业务语义是否要求“全量触达”
如果业务逻辑依赖每个节点独立执行相同动作（比如更新本机内存缓存、加载新配置、触发本地定时任务），就该用广播模式；其余绝大多数解耦、异步、幂等处理类需求，都应坚持集群模式。
切记：同一个 Group ID 下所有消费者实例必须保持订阅关系一致，否则可能引发 rebalance 异常或消息丢失。
