Disruptor Survey Report

The ticket pool tentatively uses disruptor for message queue. Sort out the recent research results on disruptor. Most of the texts are translated by disruptor and other documents on the website.

Http://www.oraclejavamagazine-digital.com/javamagazine/20120304? Pg = 56 & PM = 1 & U1 = friend # pg56

What is disruptor?

Disruptor is a framework for inter-thread communication, that is, sharing data among multiple threads. It is part of the trusted messaging architecture developed by Lmax to deliver data between multiple components in a very fast way. One of its core ideas is to understand and adapt to the way hardware works to achieve optimal results.

In many (parallel) architectures, queues are generally used to share data (such as passing messages ). Figure 1 shows a message passing through a queue (a small blue circle in it indicates a thread ). This architecture allows the production thread (stage1 in Figure 1) to continue the subsequent work when the consumption thread (stage2 in Figure 1) cannot handle it, the queue is used as the message buffer.

Figure 1

In the simplest case, disruptor can be used to replace the queue in Figure 1 architecture, that is, data is transmitted between threads through disruptor. The data structure for saving messages in disruptor is a ring buffer (ringbuffer-the term ringbuffer is used later ). The production thread stage1 puts the message into ringbuffer, and then the consumption thread stage2 reads the message from ringbuffer, 2.

Figure 2

As shown in figure 2, each element in ringbuffer has a sequence number to index. ringbuffer maintains the sequence number of the latest element, which is increasing progressively, (obtain the array subscript of the element under ringbuffer by calculating the remainder ).

The key feature of disruptor is lock-free programming, which is achieved through a single write thread-that is, a piece of data is always written by only one thread. By following this programming principle, we can avoid using expensive synchronization locks or CAS operations, which is why disruptor is so fast.

Because ringbuffer bypasses the lock, and each eventprocessor maintains its own serial number.

Publish messages to disruptor

Writing messages to the ringbuffer uses the two-step commit method. First, the production thread stage1 needs to determine the next idle slot in ringbuffer, 3.

Figure 3

Ringbuffer maintains the serial number of the last write (number 18 in figure 3), so we can infer the next idle slot number. Ringbuffer checks the serial number of all eventprocessor messages read from ringbuffer to determine whether the next slot is idle.

Figure 4 shows how to obtain the serial number of the next idle slot.

Figure 4

When the production thread obtains the next sequence profit number, it obtains the objects saved in the slot from ringbuffer and performs any operation. In this process, because the latest serial number of ringbuffer is still 18, other threads cannot read the events in the 19 slot-the production thread is still processing it.

Figure 5

Figure 5 shows the status of ringbuffer after the change is submitted. After the production thread processes the data in the No. 19th slot, it tells ringbuffer to publish the data. At this time, ringbuffer updates the maintained serial number. Any thread waiting to read the data in the 19th slot can read it.

Read Information from ringbuffer

The disruptor framework provides a batcheventprocessor to read data from the ringbuffer. When the production thread requests the serial number of the next writable idle slot to ringbuffer, an eventprocessor (similar to a consumer, however, when it consumes the elements in ringbuffer-that is, it does not remove any elements from ringbuffer), it also maintains the serial number of the last processed data and requires the serial number of the next processed data.

Figure 6 demonstrates the process of eventprocessor waiting for processing the next order profit number that can be read.

Figure 6

Eventprocessor does not directly obtain the next serial number that can read data from ringbuffer, but uses a sequencebarrier object. We will discuss this details later.

In Figure 6, eventprocessor (that is, the consumer thread stage2) finally sees the data in the No. 16th slot. It wants to process the data in the next (No. 17th) slot, therefore, it executes the waitfor (17) function call of sequencebarrier. The thread stage2 can always wait for the next readable serial number, because it does not need to do anything if no data is produced. However, as shown in figure 6, the latest available data in ringbuffer has reached the Slot 18, so waitfor returns 18, which means that eventprocessor can read all the data in the No. 18th. 7.

Figure 7

This mode provides a good batch processing behavior, you can use this batch processingCodeTo implement eventhandler, fizzbuzzeventhandler In the disruptor is a good example.

Process dependencies between system components

Disruptor is very interesting to deal with the dependency between multiple components in the system without introducing any thread competition. The disruptor follows the practice of writing data in a single thread and reading data in multiple threads. The original design of disruptor is to support several serial pipeline operations with specific sequence-this operation is common in enterprise-level systems. Figure 8 shows a standard three-step pipeline operation:

Figure 8

First, all events are written to the hard disk (log "journaling" Operation) for disaster recovery. All the second events will be backed up (replication operations) to the second server. Only after these steps are completed can the system process the actual business operations (business logic ).

It is a reasonable practice to perform these three steps in sequence, but it is not the most efficient. Logs and backup operations can be performed in parallel because they are independent of each other. However, the business operation fails because it depends on the first two. Figure 9 shows the dependency.

Figure 9

If you use disruptor, you can directly read the ringbuffer in the first two steps (log and backup. As illustrated in figure 7, they all use a barrier to obtain the next readable serial number of the ringbuffer. They maintain their own serial numbers so that they can know where they have been read and use batcheventprocessor to handle events (logs and backups ).

The business thread also reads the event from the same ringbuffer, but it can only process the events processed by the first two threads. This restriction is implemented through the second sequencebarrier. It is configured to read the serial numbers of log threads and backup threads, and return their minimum values to indicate the scope of secure read by service threads.

Data can be read from ringbuffer only when eventprocessor uses the sequence barrier to determine the range of events that can be safely handled. 10.

Figure 10

Although there are many threads reading different sequential profit numbers, as they are all simply incrementing their internal sequential profit numbers, there is no competition between threads.

Multiple production threads

Disruptor is also supported, but this article does not explain how to support it. It should be written later.

Conclusion

Although the principle of disruptor is familiar, its API is not very familiar. I wrote an experimental code to improve my understanding-but with the in-depth understanding, the code is constantly updated:

Https://github.com/shiyimin/12306ngpm/blob/8be9178d318618f905aaed45fa6025df09371c31/trunk/tpms/src/test/java/org/ng12306/tpms/DisruptorConceptProofTest.java