[HN Gopher] The LMAX Architecture (2011)
___________________________________________________________________
The LMAX Architecture (2011)
Author : mooreds
Score : 102 points
Date : 2024-08-16 15:37 UTC (1 days ago)
(HTM) web link (martinfowler.com)
(TXT) w3m dump (martinfowler.com)
| chc4 wrote:
| See also: the discussion on the LMAX disruptor github
| documentation https://news.ycombinator.com/item?id=38313457
| senderista wrote:
| So much hype for a lock-free MPMC ring buffer. If you're familiar
| with the concurrency literature you'll see that nothing here was
| novel even at the time.
| xxs wrote:
| java had a proper memory model and the busy wait was a novelty.
| iirc, it was used mostly in a single thread processing (i.e.
| consumer) for the main business logic like matching forex
| order.
|
| Realistically aside the disruptor LMAX had an interesting way
| for fail over by replaying all the input to reach the state.
| usefulcat wrote:
| I thought disruptor was SPMC? Apart from that I don't really
| disagree, I think it's just an area that a lot of people
| didn't/don't know much about.
| yxhuvud wrote:
| It comes in many variants with different properties.
| anonymousDan wrote:
| Can you point to some relevant literature?
| gpderetta wrote:
| I think that -MC is misleading. It would imply anycast (like
| what you would use for a work distribution queue), but the
| disruptor is multicast, I.e. all receivers potentially receive
| all the data. It is also lossy, like UDP.
| bostik wrote:
| It is quite fitting that another HN darling, Jane Street, uses
| similar architecture in their exchange(s).
|
| Event input queue, fully deterministic matching engine, and an
| output queue. Plus importantly, a sequencer to guarantee that the
| events going into the input queue have a known order.
|
| Aspects of their architecture and design decisions have been made
| public through their podcast series, Signals and Threads.[0]
|
| 0: https://signalsandthreads.com/
| jnordwick wrote:
| This isn't even close to unique. I['ve worked at a few HFT/MM
| places that all had a similar architecture in place before LMAX
| wrote this. This, multicast rings, and other patters are copied
| a lot in the industry because they work well for the problem
| space.
| bostik wrote:
| I'm not surprised. And I think you nailed the reason too:
|
| > _copied a lot in the industry because they work well for
| the problem space_
|
| Finance as an industry could be described as ... incestuous.
| The people move around within the small circle of firms, so
| any architectural knowledge gets cross-pollinated quite
| rapidly. From what I understand, the disruptor pattern itself
| was reasonably well known in the academic circles well before
| LMAX wrote about it - but I'm not sure anyone had put
| publicly available numbers on a heavily optimised version
| before them. (FWIW, I use a simplified disruptor in one of my
| own projects because it works well and simplifies the overall
| design. )
|
| We should also be honest about the technical challenges:
| there are _very_ few as interesting problem spaces as an
| exchange or a low-latency MM.
| richliss wrote:
| So I worked at LMAX during 2009-2011 when Martin Thompson,
| Dave Farley, Mike Barker, Chris Smith and Danny Yates
| worked on the Disruptor. It was in use in 2010 inside LMAX.
|
| The heritage of Martin and Dave was video games rather than
| finance and they had the most input into it.
|
| From a friend who worked in games, the general idea behind
| the disruptor had been in use in games for a while.
| jcelerier wrote:
| A ton of real-time audio/video apps use the same general
| architectural pattern.
| hangonhn wrote:
| Can you explain what a multicast ring is? The article itself
| just grossed over it.
|
| Thanks!
| itsthecourier wrote:
| You have many servers receiving orders in a network.
| Instead of simple TCP/IP packets, they go with multicast
| and all of them receive the same packets and keep the same
| state in memory. If one of them fails you can still depend
| on the others
| hangonhn wrote:
| Thank you!
| chrisweekly wrote:
| grossed -> glossed
|
| (aiming to help non-native English readers, vs nitpicking-
| pedantry)
| pkaye wrote:
| Is the LMAX disruptor just a ring buffer? Anything else special
| about it?
| xxs wrote:
| It is a ring buffer indeed, with publish serialization (on
| producer side) and normally a busy wait. It sort of doesn't
| work on some VMs due to scheduling. (I mean the busy wait w/o a
| backoff)
| jnordwick wrote:
| The big win is how it allows bulk processing while taking
| serialization dependencies into account.
|
| So you algos reading market data messages and yank all that
| is there and apply them in bunk instead of trying to do each
| one individually.
|
| And your logger that is storing all the messages to a file
| and/or db knows what messages the algo has processed and can
| grab all the messages up to that point so it is always
| writing as much as it can and current.
| hangonhn wrote:
| Is this ability that is the result of each component being
| able to read the index/sequence number of all the other
| components?
| qwe2645692 wrote:
| Sounds so much like an io_uring model.
| GenericCanadian wrote:
| I wrote this in Crystal lang to learn more about it and the
| language: https://github.com/nolantait/disruptor.cr
|
| There is a Ruby version that is also very readable:
| https://github.com/ileitch/disruptor
| nicholassm83 wrote:
| And here's a version in Rust:
| https://crates.io/crates/disruptor
|
| (Disclaimer: I wrote it.)
| joezydeco wrote:
| Thanks for that. I was always curious why the finance bro down
| the block had an LMAX license plate on his car.
| BrokrnAlgorithm wrote:
| Is there any didactic implementation of the Disruptor / multicast
| ring available somewhere? I've been curious in working through
| some practical example to understand the algorithm better.
| itsthecourier wrote:
| LMAX have an open source version of the disruptor in GitHub
| https://github.com/LMAX-Exchange/disruptor
| nicholassm83 wrote:
| Here's a high level description in TLA+:
| https://github.com/nicholassm/disruptor-rs/blob/main/verific...
|
| (Disclaimer: I wrote it.)
|
| There's also a spec for a Multi Producer Multi Consumer (MPMC)
| Disrupter.
| whoevercares wrote:
| Fun fact, log4j use disrupter
| bob1029 wrote:
| One of my favorite patterns.
|
| The implementations of this for C# support a value type as the
| buffer object. You can get upward of a half billion events per
| second in a SPSC arrangement.
|
| My use cases for it are primarily in gaming or where I have a
| latency critical element. C#/.NET isn't necessarily ideal for
| these use cases, but you can do clever things like align GC to
| the disruptor batch processing boundaries.
|
| If you are finding trouble with this pattern on small machines
| (1-2 cores), consider adding a heuristic that checks the core
| count of the machine and swaps from busy to a yielding wait
| strategy if there aren't at least 4 cores. Yielding wait isn't
| always good enough, but it definitely works for testing and
| prototyping.
| neonsunset wrote:
| Is the company that uses this perchance located in Europe?
___________________________________________________________________
(page generated 2024-08-17 23:02 UTC)