Questions about usage scenarios about disruptor

[Palmr]

Hello, sorry for the delayed response.

should some time-consuming operations not be directly related to the framework, such as EventHandler processing logic should not be involved in processing some database interactions and long process processing?

I think you're asking if it's okay to have blocking operations in EventHandlers?
If so, the answer is yes, there is no hard rule against blocking operations like database interactions.
The main point of the Disruptor is a queue, it can buffer up events while slower consumers handle those events.

Obviously if the rate events get inserted into the buffer is sustained at a higher rate than the consumers handle them, eventually it will wrap and you'll have to decide what to do about that.

But if the buffer is appropriately sized, and the event rate is bursty, this may be a perfectly fine thing to do.

Is the so-called super-high concurrency only for the data distribution of the data structure itself?

Yes, the high performance low latency mentioned on this project is just about the Disruptor. You can still write slow code using it, and you don't have to be aiming for high performance. But if you do want high performance inter-thread messaging, this library is unlikely to be your bottleneck. And if it is, there's not many alternatives out there that are as fast or faster.

What is the most appropriate scenario for us to use this framework in general?

Passing events between threads.

An example might be a service with a thread for receiving network events and deserialising them, that might pass those events to an application logic thread which does some work before sending out via multiple other threads to different network sockets.

In the above example you might use a Disruptor ringbuffer to buffer the events between all the threads, since the application logic in the middle will typically run at a different rate to threads dealing with blocking IO on the network. The buffers may help you cope with temporary blocking and give you other options to rewind and re-send events should packets go missing.