Kafka 历史回放怎么做才安全？换一个消费组就够了吗？
面试怎么回答
我会把回放分成输入范围、计算状态和输出影响三层。独立消费组只能隔离位点，还要使用独立检查点、结果目标及明确的副作用策略。回放前固定各分区起止范围和规则版本，限制资源与下游速率；先写影子结果做业务对账，再按受控流程切换。通知、扣款等外部动作不能随历史重算再次执行，单纯幂等表写也覆盖不了所有副作用。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
补算上个月数据，新建了一个消费者组，线上位点确实没动。可下游数据库突然出现重复通知，接口调用量也翻了上去。原来隔离的是消费进度，处理逻辑仍然在调用同一套外部服务。换组不等于隔离业务影响。
消费组只隔离消费进度，不隔离数据库、外部接口和资源；历史回放必须显式约束输出、副作用与恢复范围。
消费组隔离，只有一层边界
不同消费者组可以维护各自消费进度，但它们仍然可能读取相同Broker、调用相同维度接口、写入同一张数据库表。
如果程序把结果发到线上通知Topic，或者直接调用业务接口，新组会重新触发这些动作。哪怕结果表有主键，外部通知也未必能被同一个幂等键覆盖。
因此回放方案不能只写“新建group.id”。需要列出所有输出端和副作用，包括数据库、缓存、文件、消息、告警、计费和第三方接口。
起点容易记录，终点也不能缺
历史重算应记录每个分区的起止位点，通常用半开范围表达：包含起点，不包含终点。只指定起点而持续追最新，可能让一次历史回放变成另一条永久实时任务。
按业务时间回放时，要知道时间筛选与日志位点不是同一个范围。可能需要先定位较宽日志范围，再用业务时间过滤；迟到事件和时间戳含义会影响覆盖。
同时核对源日志是否仍然保留。设置最早位点只能读取目前存在的最早数据，不能把已经过期的历史重新找回来；缺失部分需要其他可信来源。
状态与输出都要独立
除消费组外，流处理检查点目录、状态存储、缓存命名空间和作业标识也要检查。误用原检查点可能直接带入旧状态，导致所谓从头重算实际上没有从头开始。
输出可以先落到影子表或带独立回放批次的区域，再做对账。若确实需要直接修正线上结果，应先定义覆盖粒度、旧值处理、幂等键及并发写入规则。
副作用开关要在所有出口生效，不是主流程里加一个if就结束。重试分支、异常补偿和异步回调也可能发送通知，应该纳入测试。
一个典型场景：表没重复，通知却重复发了
比如结果表使用订单主键UPSERT，回放后行数保持稳定，团队据此判断幂等成立。用户却再次收到历史订单完成通知。
最初怀疑消息队列重复投递，进一步追踪发现通知是回放任务主动发出的。根因是把数据库写入幂等等同于整条业务处理幂等。
旧验收只比较目标表主键和金额，没有统计外部动作。修复应把计算与业务动作分开，历史重算默认仅生成数据结果，必要的业务补偿由独立受控流程执行。
测试可以使用可观测的替身出口，检查回放期间外部调用次数确实为零；仅在日志里写一句“dry run”并不能证明隔离有效。
还要防止回放挤占线上容量
独立作业不等于独立资源。Broker读取、对象存储、数据库写入和维度查询都可能共享瓶颈，应设置速率、并发和运行窗口。
对账时固定比较范围、输入版本和规则版本，分别检查业务键覆盖、金额、状态及异常去向。新逻辑与旧逻辑存在预期差异时，必须解释差异，不是追求所有数字机械相等。
切换前保留旧结果与发布清单，明确失败时如何恢复。回放成功和正式发布是两个动作，不应因为任务结束就自动覆盖所有线上产物。
安全回放真正需要回答的是：这次要重算哪些数据、影响哪些系统、哪些动作绝不能发生，以及如何证明新结果值得被采用。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。