Question

I would like to maintain a list of objects that is distributed between N load balanced servers: whenever a client changes the list on one server, I would like these changes to migrate to the other servers. So, I guess this is a case of master-master replication.
What is the simplest way of handling this? One simplifying fact is that each change to an object in the list has an associated increasing version number attached to it. So, it is possible to resolve conflicts if an item was changed on two different servers, and these two deltas make their way to a third server.

Edit: clarification: I am quite familiar with distributed key-value stores like Memcached and Redis. That is not the issue here; what I am interested in is a mechanism to resolve conflicts in a shared list: if server A changes an item in the list, and server B removes the item, for example, how to resolve the conflict programmatically.

Answer 1

Put your changes in a queue. Have each server look at the queue, and act upon it.

For example, queue could have:

• add item #33
• remove item #55
• update item #22
• and so on

Upon doing a change, write to the queue, and have each server pick up items from the queue and update its list according to that.

I did in-memory database with such method, and it worked perfectly on multiple ‘servers’.

EDIT:

When servers want to update each other, that has to happen:

Each server that updates will put an UPDATE (or ADD or DELETE) request into the queue for all other servers. Each server should also store the list of queued requests that originated from it so it will not load its own updates from the queue.