May 23, 2018

[LMAX][ACTOR MODEL][Note] A bit about LMAX

Reference:
[AKKA] How the Actor Model Meets the Needs of Modern, Distributed Systems
[AKKA] What problems does the actor model solve?



[Video] The Actor Model (everything you wanted to know...)


  • Processing
  • Storage
  • Communication

One actor is no actor

Actor comes in system
Actor has address
Everything is an actor


When actor receives messages, it can

  • Create more actors
  • Send messages to other actors that it has the addresses to send to
  • Designate what to do with the next message it receives


Future

They are actors can be send around(like a lambda expression/closure)


Address

Address : Actor is many-to-many arch.


Message

Messages are received NO guarantee in order.

It's like the IP(not TCP) model.
IP sequence without considering order(upper layer will do the check).

Sender persists message.

There's NO channels.

Same message can be send at MOST 1 time. No duplicate.

Message sent is not time-bounded. Which can take a long time to arrive to another actor.

Message being handled one at a time, which gives us synchronization.


non-deterministic vs. in-deterministic

Nondeterministic (turing) vs Indeterministic (actors)

E.g: A message that increments a number and then sends the same message again.
Another message, to stop and report the number is on its way. How many increments can happen before the stop message arrives.


arbiter

  • Not something you can make out of just (and gates/or gates) and other boolean components.
  • Equal number of outputs to inputs. 
  • The output order is not determined by the order of input. 
  • Unbounded by processing time but the probability of output goes down exponentially as time goes on. 
  • Mutated state isn't for the current message.
    Mutated state is for the next message.




LMAX

Paper:

Disruptor: High performance alternative to bounded queues for exchanging data between concurrent threads
(neat paper touch the basic idea of MESI / false sharing / prefetch etc.)


The LMAX Architecture
  • Event sourcing (log, RAFT)
  • snapshot (RAFT, taking snap shot with commited log)
  • unlike RAFT, Business Logic Processor keep multiple active node, each input event is processed by multiple active node.

Concurrent execution of code is about two things:
  • mutual exclusion and
  • visibility of change.


CAS approach is significantly more efficient than locks because it does not require a context switch to the kernel for arbitration.

However CAS operations are not free of cost.
(Details can be read from book: The art of multiprocessor programming)

The processor must lock its instruction pipeline to ensure atomicity and employ a memory barrier to make the changes visible to other threads.

The ideal algorithm would be one with only a single thread owning all writes to a single resource with other threads reading the results.

To read the results in a multi-processor environment requires memory barriers to make the changes
visible to threads running on other processors.


Solution:
Ensuring that any data should be owned by only one thread for write access, therefore eliminating write contention.


When designing a financial exchange in a language that uses garbage collection, too much memory allocation can be problematic. (golang, and the benefit of using C++)

The LMAX Architecture
https://martinfowler.com/articles/lmax.html

The best programmers prefer profilers and test cases to speculation.

reference:
https://en.wikipedia.org/wiki/Little%27s_law
Ring buffer basics
Circular Buffers in C/C++

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.