Replicating shared memory

[Prashanth Reddy]

Hi,

I've a system design question, which is somewhat related to the topics discussed on this group. So I am posting it here.

Let's say we have a system which sends orders to exchanges. It maintains the order state and other information in shared memory (e.g., /dev/shm/state_file1, /dev/shm/state_file2, ..., /dev/shm/state_fileN). When an order goes out, several shared memory files are updated and when messages are received from the exchanges, several shared memory files are updated. We need to replicate the state (all the relevant files in shared memory) to another box for disaster recovery. The system is handling 1000s of orders a second and the state should be replicated in near-real-time. So, my existing solution, has a process running on the box. It is separate from the order entry/management engine. It figures out which shared memory files change when the messages arrive, reads the relevant portion of the file, makes a message with the contents and sends a message to listener process on another box. The listener process writes the messages to disk. The problem is in figuring out what changes when an order is sent and when a message arrives - a big chunk of the logic in the order entry/management engine is also in the process which publishes the messages. 

Is there any other way to do this?

Thanks for your time.

-Prashanth.

[Greg Young]

Use a replicated log and have both sides listen on commit? Getting a
stock replicated log to handle 1000s of orders/second shouldn't be a
big deal.

> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-symp...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[ymo]

You could use something like aeron logs for this. The nice thing about it is that it is a storage as well as a transport format. Once you figure how to send/receive from/to the orders to the "listener process on another box" via aeron you will also have the sent bytes stored locally on a rolling log. At some point Aeron "might"add replicated (or multicasted) logs but that is something you could sponsor as a company .. wink/wink )))

[Harnit Bakshi]

We have started looking at Chronicle Queue for real time replication, there is also ChronicleMap which supports replication of deltas only. From reading the above seems like you are doing replication asynchronously?

Harnit

[Prashanth]

Yes, we are doing it asynchronously. I'll explore Chronicle Queue and Chronicle Map.

--
You received this message because you are subscribed to a topic in the Google Groups "mechanical-sympathy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mechanical-sympathy/iLRwAKUVx1E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mechanical-symp...@googlegroups.com.

[Roman Leventov]

Correction: out of the box, Chronicle Map doesn't replicate deltas, on the contrary, it replicates entire values. However, there is undocumented "private" API (used, for example, by Chronicle Engine), allowing to implement delta replication, or any different bespoke strategy.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Harnit Bakshi]

Sorry my bad thanks for the correction!

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.