3424672656 commented on PR #11157: URL: https://github.com/apache/rocketmq/pull/11157#issuecomment-5748890454
> > _这是人工智能在分诊过程中生成的。_ > > 我再次查看了最新的主分支（`b3b7490`）。这个 PR 解决了一个实际的正确性和性能问题`TimelineRollService`：旧的固定睡眠循环扫描的窗口大小类似于`[now + rollRange, now + rollRange + timerMaxDelaySec]`，因此相邻的滚动轮次重叠严重，可能会反复将相同的远期计时器记录回滚到`TIMER_TOPIC`。改用`[checkpoint, checkpoint + rollRange)`带有专用检查点的扫描（）`timeline_roll_checkpoint`才是正确的方向。 > > 最新版本还通过将检查点持久性移至`TimerMessageReputService`排队滚动批处理完成后，而不是在扫描后立即写入，解决了之前出现的崩溃跳过问题。 > > 合并前还有一个正确性问题：`TimerMessageReputService`检查点会在所有任务倒计时结束后写入，但各个任务不会报告是否`putMsgWithRetry()`实际成功。`putMsgWithRetry()`目前，`void`重试次数用尽后才会返回并记录日志。如果一个或多个记录未能重新写入提交日志，服务仍然可以继续执行`TIMELINE_ROLL_CHECK_POINT`，从而剥夺了这些失败记录的正常提前重试机会。 > > 建议的解决方法：让每个任务返回成功/失败，并且只有当整个批次成功时才写入滚动检查点，或者避免将检查点推进到失败的记录之后。 > > 兼容性说明：此 PR 移除了 `<script>` 标签`timerRocksDBRollIntervalHours`，`timerRocksDBRollRangeHours`现在可同时控制扫描窗口宽度和滚动频率。请在配置文档/发布说明中记录此更改，因为使用自定义滚动间隔的部署可能会出现行为变化。 > > CI 为绿色，并且一旦处理了失败信誉检查点边缘，基于检查点的整体设计看起来是合理的。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
