[GitHub] [rocketmq] cdmaji opened a new issue, #5445: 线上环境出现的一次resetoffset的bug

Tue, 01 Nov 2022 05:10:12 -0700 


cdmaji opened a new issue, #5445:
URL: https://github.com/apache/rocketmq/issues/5445

   版本：v4.2.0+
   问题描述：通过resetOffsetByTime重置位置点，发现重置位置点不能准确定位到目标的位置。
   相关代码：org.apache.rocketmq.store.ConsumeQueue getOffsetInQueueByTime()
   org.apache.rocketmq.store.CommitLog putMessages(final MessageExtBatch 
messageExtBatch)
   关于生产消息的时候，如果是batch生产消息，在存储和落盘的时候这一批消息的BornTimestamp是一致的：
   
![image](https://user-images.githubusercontent.com/13196820/199229249-3f254779-9fe8-4824-abcc-cf7af9fb1212.png)
   对于消息整体流程来说是合理的，因为一批的消息确实应该是一个时间。但是在重置位置点的时候，实际是按照BornTimestamp去做的二分查找：
   
![image](https://user-images.githubusercontent.com/13196820/199229336-a6142a2a-438c-4069-969b-712fed8da730.png)
   
这样会导致概率性的出现重置位置点不准确的问题（比如大部分的需求都是重置到这一批消息的第一条消息，但是按照二分算法，和消息条数有关系完全有可能处于中间的某条）。在我们实际线上环境中，业务方会比较纠结这个问题，总是重置不到理想位置。
   针对这个问题，其实有两种解决思路：
   1、修改broker端存储BornTimestamp；
   2、修改二分算法，利用二分结果再去左右匹配直到匹配到左边第一条；
   
   
个人比较建议第二种方式，虽然性能上略有损耗，但是比较resetOffset是一个运维工具，没有必要去改变存储，而且如果修改BornTimestamp后也不太能判断N条消息是否为一批消息。


-- 
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]

Reply via email to