rocketmq消费进度管理与容错处理核心是消费者主动上报offset、broker统一协调，集群模式下offset远程存储并每5秒批量提交最小成功offset，广播模式下本地文件存储；消费成功与否取决于回调返回consume_success或reconsume_later，失败消息经16次递增延迟重试后入dlq，新实例按consumefromwhere策略（默认consume_from_last_offset）启动消费。
RocketMQ 消费者端的消费进度管理与容错处理，核心围绕“消息不丢、至少成功一次、可恢复、可干预”四个目标展开。它不是靠 Broker 主动追踪，而是由消费者主动上报 + Broker 统一协调，配合明确的 ACK 语义和重试机制来实现。
消费进度怎么存、怎么同步
消费进度（offset）以 Consumer Group + MessageQueue 为粒度维护，每个队列一个独立偏移量。
- 集群消费模式下，进度由消费者定时上报至 Broker（远程存储），Broker 持久化到磁盘；本地只缓存最新值，宕机后未同步的 offset 会丢失，导致少量重复消费
- 广播消费模式下，每个消费者独立保存进度到本地文件（LocalFileOffsetStore），不与其他实例共享，也不上报 Broker
- 上报不是实时的：默认每 5 秒批量提交一次，且只提交已成功消费的最小 offset（例如拉取了 [100–110]，仅 100 失败、其余全成功，最终提交的仍是 100）
消费成功与失败的判定标准
是否算“消费完成”，完全取决于业务回调函数的返回值，不是看有没有抛异常，也不是看有没有执行完逻辑。
- 返回 ConsumeConcurrentlyStatus.CONSUME_SUCCESS：RocketMQ 认定这批消息（默认 1 条）已成功，后续将推进 offset 并清理本地缓存
- 返回 ConsumeConcurrentlyStatus.RECONSUME_LATER：明确告知需重试，消息会被发往该 Consumer Group 对应的 RETRY Topic，延迟后再次投递
- 未显式返回、或回调中抛出未捕获异常：等效于 RECONSUME_LATER，自动触发重试
- 顺序消费（MessageListenerOrderly）不支持 RECONSUME_LATER，失败时只能暂停当前队列，直到该消息重试成功才继续
重试与死信：失败消息怎么兜底
重试不是无限循环，而是有节奏、有终点的容错路径：
- 首次重试默认延迟 10 秒（可配置），后续每次失败延迟等级递增，共 16 级（从 1s → 2h 不等）
- 第 16 次重试仍失败后，消息被投递到 DLQ（Dead Letter Queue），Topic 名为 %DLQ%+ConsumerGroup
- DLQ 中的消息不会被自动消费，需人工介入排查（如查库失败原因、修复数据、或跳过）
- 注意：RETRY 和 DLQ 的消息都使用新 msgId，原 msgId 不再复用，便于追踪链路
启动时从哪开始消费
新消费者实例启动时，首先向 Broker 查询本 Group 在各 Queue 的历史 offset；若无记录（全新 Group），则按 consumeFromWhere 策略决定起点：
- CONSUME_FROM_LAST_OFFSET（默认）：从当前队列尾部开始，跳过所有存量消息
- CONSUME_FROM_FIRST_OFFSET：从队列头部开始，消费所有可读的历史消息（需确保消息未过期）
- CONSUME_FROM_TIMESTAMP：从指定时间戳之后的第一条消息开始，常用于故障恢复或补数
容错不是靠系统自动兜底，而是靠清晰的语义边界 + 可控的重试策略 + 明确的失败出口。业务只需守住两个关键点：正确返回状态码、做好消费幂等，其余由 RocketMQ 保障。
