[Feature] Support disruptor as memory queue

[qqeasonchen]

Search before asking

• I had searched in the issues and found no similar issues.

Feature Request

Support disruptor[1] as memory queue, for event processing.

1. https://github.com/LMAX-Exchange/disruptor

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct *

[jevinjiang]

I want to try it. Can you tell me where to start？

[Pil0tXia]

@jevinjiang The existing standalone storage-plugin used a BlockingQueue as Event Store in EventMesh Runtime JVM memory. We'd like to use disrupter to substitue BlockingQueue.

[jevinjiang]

@Pil0tXia thank you~
Let me confirm what I need to do:
Replacing org.apache.eventmesh.storage.standalone.broker.MessageQueue(BlockingQueue) with disruptor in standalone storage-plugin

[jevinjiang]

I have a question while modifying the MessageQueue. If there are no subscribers, can I create a MessageQueue to store messages? 我有一个疑问， 如果说一个messageQueue不存在订阅者，我应该创建它吗

[jevinjiang]

I think disruptor is not suitable for long-term storage of events。

[Pil0tXia]

while modifying the MessageQueue. If there are no subscribers, can I create a MessageQueue to store messages?

The ideal relationship between producer, MessageQueue, and consumer is one-to-one-to-one. A consumer cannot subscribe to or retrieve messages from a non-existent MessageQueue. If the consumer declares the queue, there is a potential risk of discarding messages sent by the producer before declaring the queue. After a producer creates a new MessageQueue, you need to ensure that there is a corresponding consumer subscribing to this queue.

I think disruptor is not suitable for long-term storage of events

Messages stored in standalone mode will be lost after a reboot. This is acceptable.