Disruptor 2.0 - All Change Please. Martin recently announced version 2.0 of the Disruptor - basically there have been so many changes since we first open-sourced it that it's time to mark that officially.
His post goes over all the changes, the aim of this article is to attempt to translate my previous blog posts into new-world-speak, since it's going to take a long time to re-write each of them all over again. Now I see the disadvantage of hand-drawing everything. In the old world This is an example of a configuration of the Disruptor (specifically a diamond configuration). If none of this means anything to you, feel free to go back and refresh yourself on all the (now outdated) Disruptor details.
The most obvious changes over the last few weeks have been: Updated naming conventionIntegrating the producer barrier into the ring bufferAdding the Disruptor wizard into the main code base. The New World Order You'll see the fundamentals are pretty much the same. Note there is a Wiki page on the Disruptor Wizard. Dissecting the Disruptor: Wiring up the dependencies. So now I've covered the ring buffer itself, reading from it and writing to it.
Logically the next thing to do is to wire everything up together. I talked about multiple producers - they have the producer barrier to keep them in order and under control. I've talked about consumers in a simple situation. Multiple consumers can get a little more involved. We've done some clever stuff to allow the consumers to be dependent on each other and the ring buffer. The Disruptor paper and the performance tests cover some basic configurations that you might want. Diamond configurationDiamondPath1P3CPerfTest illustrates a configuration which is not too uncommon - a single producer with three consumers.
Consumer three might be your business logic, consumer one could be backing up the data received, and consumer two may be preparing the data or something. Diamond configuration using queues In a SEDA-style architecture, each stage will be separated by a queue: (Why does queue have to have so many "e"s? Video of our JAX London session. The LMAX Architecture. LMAX is a new retail financial trading platform.
As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread. The Business Logic Processor runs entirely in-memory using event sourcing. The Business Logic Processor is surrounded by Disruptors - a concurrency component that implements a network of queues that operate without needing locks.
During the design process the team concluded that recent directions in high-performance concurrency models using queues are fundamentally at odds with modern CPU design. Over the last few years we keep hearing that "the free lunch is over"[1] - we can't expect increases in individual CPU speed. So I was fascinated to hear about a talk at QCon London in March last year from LMAX. Overall Structure Figure 1: LMAX's architecture in three blobs At a top level, the architecture has three parts Business Logic Processor. Circular-buffers.txt. Disruptor - Concurrent Programming Framework. LMAX Blogs.