[Enhancement] In scenarios where immediate message retrieval is highly unlikely, avoid waking up PopRequests

[redlsz]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

In the current implementation, if there is a backlog of messages after popRequest done, PopMessageProcessor will try to wake up waiting PopRequests to optimize consumption delay.

But in scenarios where immediate message retrieval is highly unlikely, such wake-ups may result in a large amount of unnecessary polling. eg:

1. Pop queue operations are being throttled due to too many in-flight messages.
2. Pop queue operations experience heavy lock contention.

Motivation

We observed that the number of PopRequests processed per second exceeded 30w, placing heavy load on the CPU.

Describe the Solution You'd Like

In scenarios where immediate message retrieval is highly unlikely, avoid waking up PopRequests.

Describe Alternatives You've Considered

/

Additional Context

No response

[lizhimins]

In the first scenario, the rest count will not accumulate when the cache is full.

[lizhimins]

rocksdb cq 没有实现快速向后 filter 的能力，应该把 文件版 cq maxFilterMessageSize 这个能力移植过来