[erlang-questions] Is Erlang ideal for a global exchange?

xu xiut xiut.xu@REDACTED
Wed Jan 14 16:38:33 CET 2015


T Ty, Sean Cribbs thinks Riak and Disruptor have very little in common:
http://riak-users.197444.n3.nabble.com/Disruptor-like-behaviour-td4032394.html

On Wed, Jan 14, 2015 at 9:04 AM, xu xiut <xiut.xu@REDACTED> wrote:

> https://github.com/LMAX-Exchange/disruptor/wiki/Introduction
>
> Does the disruptor still sound like Riak?
>
> On Tue, Jan 13, 2015 at 10:36 AM, T Ty <tty.erlang@REDACTED> wrote:
>
>> Your comment is quite interesting. My take-away from reading the LMAX
>> article wasn't the single threaded business logic process nor the shared
>> memory communication.
>>
>> My take-aways were:
>>
>> 1. pipelining. Do all input validation and transformation before/after
>> main business logic processing. This makes coding the 'happy-path' easier
>> and keeps the business logic core small.
>>
>> 2. the business logic process is a master process that reacts to events
>> and generate events. This allows scaling of the business logic process as
>> it makes it easier to spawn processes to deal with the events.
>> (gen_event/gen_fsm triggering supervisor in simple_one_for_one that starts
>> other processes)
>>
>> 3. Event Sourcing. One added benefit is compliance. It is easier to
>> demonstrate compliance when there are events to show how the system changed
>> from one state to another. Compliance here can mean security compliance or
>> regulatory compliance.
>>
>> 4. business logic processor deals with events in-memory. mnesia
>> ram_tables fit this criteria easily as do ets tables.
>>
>> 5. Business Logic State Snapshot. Not only does this allow resilience
>> between node restarts it also allows migrating the partial process to a
>> different node entirely.
>>
>> 6. Avoiding external service calls in the Business Logic process.
>> Transition to an event based model for interacting with external services.
>> Have a middle layer of gen_fsm to determine where in the logic the current
>> process is in.
>>
>> 7. Mention about session data being transient and can be discarded. Aka
>> let process die and supervisor restart.
>>
>> The Disruptor sounds like Riak.
>>
>> Cheers
>>
>> On Tue, Jan 13, 2015 at 2:11 PM, Mihai Balea <mihai@REDACTED> wrote:
>>
>>>
>>> > On Jan 12, 2015, at 4:10 AM, T Ty <tty.erlang@REDACTED> wrote:
>>> >
>>> > The LMAX architecture is an easy fit for Erlang and one which an
>>> Erlanger would naturally arrive to.
>>>
>>> I beg to differ. LMAX uses a single threaded process to implement its
>>> entire business logic, which makes it highly sensitive to sequential
>>> performance. This is not one of Erlang’s strong points. Also, the
>>> disruptors - which are essentially fancy circular buffers - depend on
>>> preallocated memory and destructive updates to attain their performance.
>>> Finally, the communication between various stages in the pipeline is done
>>> through shared memory, and they do some clever tricks to avoid locking.
>>>
>>> Yes, you could emulate this architecture in Erlang, but you won’t get
>>> anywhere near LMAX’s performance.
>>>
>>> Mihai
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150114/3e05790e/attachment.htm>


More information about the erlang-questions mailing list