消费者位点重置有哪些风险？

简化版

位点向前重置会跳过消息并造成漏消费，向后重置会重复消费并可能覆盖新状态。操作前必须冻结或隔离消费组，保存原位点，明确 Topic、分区、时间到 offset 的映射，并确认消费者幂等、Schema 兼容和下游容量。

位点是消费组对每个分区的进度，不是 Topic 的全局游标。按时间重置时各分区映射结果不同，保留期外消息可能已删除；运行中的消费者还可能提交新位点覆盖人工设置。安全流程是审批、停消费、快照原位点、计算并复核目标、用影子组小范围验证、执行后监控与对账。

重放需要独立幂等键或重放命名空间，避免再次扣款、发券和通知。若旧消息 Schema 已不兼容，先做转换或使用对应版本消费者；完成后记录操作者、原因、前后位点和影响量，并保留可执行的位点恢复方案，同时明确它不能撤销已经发生的业务副作用。

Kafka 类系统的 offset 只在单个分区内有意义，消费组为每个分区保存一个位置。不能用“Topic offset=1000”描述全局进度；分区 0 的 1000 与分区 1 的 1000 对应不同消息和时间。

易错点：重置的是“消费组 × Topic × 分区”的状态矩阵，不是一根全局指针。

向前从 1000 跳到 1500，会在新位点下略过 [1000,1499]；若后续没有专门补放，这部分就形成漏消费。向后从 1500 回到 1000，会重放 500 条。跳过可能造成数据缺失，重放可能造成重复副作用；两者都不是普通配置调整。

消费者仍运行时可能已拉取旧位置之后的数据，并周期提交自己的 offset。管理员刚写入目标位点，消费者下一次提交又把它覆盖；内存中的消息还可能在重置后继续落库。应停止组、等待成员离开并确认没有活跃提交，再修改位置。

freeze -> snapshot offsets -> verify group empty
       -> set target offsets -> start controlled consumers

Kafka 类接口通常按分区返回时间戳不小于目标时间的最早 offset，而不是返回绝对时间差最近的消息；不同产品的映射语义还需以接口文档为准。生产者时钟错误、消息延迟到达和时间类型配置都会影响结果。目标时间早于保留窗口时，旧消息已经不可恢复；查找可能落到当前最早位置或返回空值，必须逐分区检查。

例如 8 个分区各回放约 10 万条，总量约 80 万；不能拿一个分区的估算直接当全局数量。

数据库 upsert 不代表所有副作用幂等：短信、邮件、支付和第三方调用可能再次发生。消费处理应以 eventId/业务键建立去重记录，状态迁移检查当前版本；必要时在 replay 模式禁用通知，只重建指定派生数据。

旧事件还可能使用已下线字段或语义，消费者要支持版本路由、转换层或使用历史版本程序，不能只保证 JSON 能解析。

先复制原位点和目标估算到变更单，使用新消费组或少量分区演练，再控制消费速率。观察重复命中、失败率、下游 P99、lag 和业务差异。完成后不要立即删除原快照，以便错误方向或目标算错时恢复读取位置；已经落库或发出的副作用仍要另行补偿，不能靠恢复 offset 回滚。

审计至少记录操作者、审批、原因、Topic、group、每分区 old/new offset、预计消息量、开始结束时间与校验结果。

压缩 Topic 只保留每个 key 的较新记录，向后重置也不代表能看到完整历史；事务消息还要遵守隔离级别，不能把已中止记录当作可重放业务事件。

因此重放能力应在平时用归档和演练建设，不能等事故发生后才假设 Broker 保留了所有需要的数据。

位点重置按“停组—备份—逐分区计算—影子验证—限速执行—业务对账”操作。向前意味着漏，向后意味着重；安全性取决于幂等、Schema 兼容、下游容量和可回滚快照，而不是命令是否成功返回。