Re:The LMAX Architecture - 100K TPS at Less than 1ms Latency
by jacques_chester on Sunday October 30, 2011 @06:49AM
(#3174076)
> It looks like they deal with inconsistency at the business logic level instead of delegating to the persistence store.
Actually it looks the other way around. As I read it, the "Input Disruptor" does the validation.
Do the three components all run in the same thread, or are they on different JVMs?
Re:The LMAX Architecture - 100K TPS at Less than 1ms Latency
by koevet on Sunday October 30, 2011 @07:00AM
(#3174084)
The Disruptor components are not part of a single threaded process, as far as I understand
"Also these three tasks are relatively independent, all of them need to be done before the Business Logic Processor works on a message, but they can done in any order. So unlike with the Business Logic Processor, where each trade changes the market for subsequent trades, there is a natural fit for concurrency."
I think that the Disruptor can run on the save JVM as the business logic, also to avoid remoting-related bottlenecks.
Re:The LMAX Architecture - 100K TPS at Less than 1ms Latency
by aaronblohowiak on Sunday October 30, 2011 @09:46AM
(#3174354)
The BLP is single-threaded, and the component that modifies the application's current state. It is my understanding that "Events" in event-sourcing are immutable and that state is just a memoized computation over the total journal of events -- so the layer of atomiticity that is provided is at the event level (as the BLP only processes one event at a time.)
Re:The LMAX Architecture - 100K TPS at Less than 1ms Latency
by jacques_chester on Sunday October 30, 2011 @11:41AM
(#3174603)
So the system is as "weak as its strongest link".
Hmm.
1. relaxed guarantees, "As a consequence the LMAX team puts a lot of attention into ensuring the input events are fully valid before doing any mutation of the in-memory persistent state.". It looks like they deal with inconsistency at the business logic level instead of delegating to the persistence store. Probably, they don't have very complex transactional logic.
2. Smart data structures, here http://disruptor.googlecode.com/files/Disruptor-1.0.pdf you have a deeper technical view of the Disruptor and the rationale behind "mechanical sympathy".