Disruptor is a high-performance queue developed by the British foreign exchange trading company LMAX. The original intention of research and development is to solve the delay problem of memory queues.
In Storm, there are some differences between the thread communication within the worker process and the communication between worker processes. The communication between workers often needs to be carried out across nodes through the network. Storm uses ZeroMQ or Netty (default after 0.9) as the message framework for inter-process communication. . Intra-worker communication or thread communication between different workers on the same node is done using the LMAX Disruptor.
For worker processes, in order to manage incoming and outgoing messages, each worker process has an independent receiving thread (listening to the configured TCP port supervisor.slots.ports). The parameter topology.receiver.buffer.size represents the maximum number of messages that the receiving thread can receive at one time, and the user can customize the configuration. The receiving thread passes the received message to the incoming-queues of the corresponding executor(s). Corresponding to the receiving thread, each worker has an independent sending thread, which is responsible for reading messages from the worker's transfer-queue and sending them to other workers through the network. The size of the transfer-queue is determined by the parameter topology.transfer.buffer.size set up. Each element of the transfer-queue actually represents a collection of tuples. When the tuple in the outgoing-queue of the executor reaches a certain threshold, the sending thread of the executor will obtain the tuple in the outgoing-queue in batches and send them to the transfer-queue middle.
Each worker process controls one or more executor threads, which can be configured by the user in code. Each executor has its own incoming-queue and outgoing-queue. A worker process runs a dedicated receiving thread to be responsible for moving externally sent messages to the incoming-queue of the corresponding executor thread. After the outgoing-queue reaches a certain threshold, the sending thread in the executor will put it in the outgoing-queue. The messages are sent to the transfer-queue of the worker in batches. The size of the incoming-queue and outgoing-queue of the executor can be customized by the user. Each executor has a separate thread to process the business logic of spout/bolt and consume data from outgoing-queue and send it to transfer-queue.