2

I have done some research with the disruptor patern and there's one thing I can't wrap my head arround.

There are the producers, which provide the entry's for the ring buffer. There is the ringbuffer, basically a fixed but endless array. There are the consumers (basically sperate threads), handling the entries from the ringbuffer.

I'm trying to relate how the disruptor patern can be used in a real case scenario of a stock market.

Usually you would have the orderbook containing all orders. How I see it, a producer would receive a new order from a broker. The producer places the order in the ringbuffer. After the order has been placed in the ringbuffer, a consumer fetches the order and cross-checks it with the orderbook.

Now here is the part where I'm having a bit of trouble understanding the advantage. If there would be multiple consumers, which is what you want for scalable system, how can there be multiple consumers handing orders?

The orderbook has to be locked when accessed by a consumer to ensure integrity. What I'm looking for is an answer to this question and a rough idea how a order matching engine could possibly benefit from this patern.

LMAX has their own order matching engine, so there has to be something I'm overlooking.

Thank you

user3014924
  • 153
  • 4

1 Answers1

3

they have a single consumer handling the orders themselves. the rest of the consumers act on this order processors' output - things like returning responses, writing logs, writing to database etc. actual order processing takes place on a single thread, which is the only thread to access the orderbook and so does not need to lock it.

they claim to be able to do up to 6 million orders/sec on this single thread.

radai
  • 23,949
  • 10
  • 71
  • 115
  • 2
    Exactly. The single most important thing about the LMAX architecture (as they have described it in public!) is that there is a single thread doing the actual order matching, which is able to communicate with the input and output threads without locking. That means that although the work is being done by a single thread, it is able to run at immense speed. This approach does not scale with additional cores, but that doesn't matter, because it's easily fast enough on a single core. – Tom Anderson Nov 20 '13 at 21:47
  • Thank you for your answer Radai and Tom Anderson. But then the question arrises: – user3014924 Nov 21 '13 at 00:18
  • Thank you for your answer Radai and Tom Anderson. Based on your answers I'm beginning to think Disruptor should be seen as a mean to structurally process actions in a non-concurrent but paralel way. What Disruptor is not, is a patern for fast order matching. Am I right? – user3014924 Nov 21 '13 at 00:26
  • @user3014924 that is correct, it is not a pattern for fast order matching, it is structural. It provides a way to decouple the speed of incoming orders from their processing -- like a buffer between the incoming orders and their processing. It is basically a simple "queue". But typical Java queue collections that are accessed by multiple threads end up having significant overhead due to CPU cache coherency effects. Disruptor, by placing the restriction of a single producer, and achieve efficiencies not available to standard collections. – brettw Nov 21 '13 at 02:35