[improve][broker] Reduce memory occupation of the delayed message queue

[thetumbled]

Motivation

Delayed queue consume a lot of memory to store the message id. We can reduce the memory occupation with new data structure simillar to #23601.

Modifications

Use new data structure to reduce memory occupation of the delayed message queue, InMemoryDelayedDeliveryTracker.

List some experiment data with following test code:

 static long trimLowerBit(long timestamp, int bits) {
        return timestamp & (-1L << bits);
    }

    public static void main(String[] args) throws IOException {
        TripleLongPriorityQueue queue = new TripleLongPriorityQueue();
        Long2ObjectSortedMap<Long2ObjectSortedMap<Roaring64Bitmap>> map2 = new Long2ObjectAVLTreeMap<>();
        
        int trimLowerBits = 10, messagePerMs = 8, tick=0;
        long numMessages = 10000000, entriesPerLedger = 50000, numLedgers = numMessages / entriesPerLedger;
        long ledgerId, entryId, timestamp=System.currentTimeMillis(), tmp=0;
        for (long i = 0; i < numLedgers; i++) {
            ledgerId = 10000+i;
            for (long j = 0; j < entriesPerLedger; j++) {
                entryId = 10000+j;
                // 1 messages per ms default
                if (tick++ % messagePerMs == 0){
                    timestamp++;
                }
                queue.add(timestamp, ledgerId, entryId);                
                tmp = trimLowerBit(timestamp, trimLowerBits);
                map2.computeIfAbsent(tmp, k -> new Long2ObjectAVLTreeMap<>())
                    .computeIfAbsent(ledgerId, k -> new Roaring64Bitmap())
                    .add(entryId);
            }
        }
        System.out.println("queue size in MB: " + queue.bytesCapacity() / 1024.0 / 1024.0);    

        try {
            Thread.sleep(10000000);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("map2 size: " + map2.size());
    }

Produce 1kw entries with 1k ledgers, with the speed of 1 msg/ms.

• Original data structure: TripleLongPriorityQueue
  It store the info in the direct memory, we can call queue.bytesCapacity() to get the size of memory it take.
  
  So, TripleLongPriorityQueue take up 240MB.

• New data structure: Long2ObjectSortedMap<Long2ObjectMap<Roaring64Bitmap>>
  It store the data in heap, so we can use jmap to dump the memory to analyze.
  

So, it take up only 11MB, down to only 11/240=4.5% of the original size!

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is already covered by existing tests, such as (please describe tests).

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: thetumbled#65

[dao-jun]

Good work, and I'm just wandering how much memories can we reduce?

[thetumbled]

Good work, and I'm just wandering how much memories can we reduce?

Updated in the PR.

[lhotari]

LGTM. Great improvement! Thanks for the contribution @thetumbled