1

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.

Jacko
  • 12,665
  • 18
  • 75
  • 126
  • What code do you have thus far...? – MethodMan Dec 26 '11 at 01:25
  • 2
    Please don't prefix your titles with "c#: ". That's what the tags are for. – John Saunders Dec 30 '11 at 17:13
  • What is your question exactly ? – Yahia Dec 30 '11 at 17:16
  • I'm not to failure but didn't MSFT build something like this with Azure that you can use? I mean it really seems like your re-inventing the wheel for no reason. – Brad Semrad Dec 30 '11 at 17:17
  • 1
    @Jacko thanks for the update... it is still a bit unclear... conflict resolution in the case you describe depends on the use case... either you can describe the use case or the answer can only be to make the "conflict resolution policy" on the shared list configurable... there are several policies like "write-through", MVVC etc. used in real-worlds projects... – Yahia Dec 30 '11 at 17:57

5 Answers5

4

I suggest memcached. It's a distributed server cache system that seems to fit your needs perfectly. Check out this link:

Which .NET Memcached client do you use, EnyimMemcached vs. BeITMemcached?

If passing the entire list doesn't suit you (I don't know if memcached is smart enough to diff your lists) then I would suggest giving the old DataSet object a look, as its diff grams should be well suited for passing about just deltas if your data set is large.

Community
  • 1
  • 1
Malachi
  • 2,260
  • 3
  • 27
  • 40
  • Thanks, its not the storage that concerns me, it is designing the distributed part: i.e. how to manage conflicts, etc. – Jacko Dec 27 '11 at 14:30
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.

Daniel Mošmondor
  • 19,718
  • 12
  • 58
  • 99
  • Thanks. What about if server A updates item #22, and server B updates item #22..... how to resolve the conflict? – Jacko Dec 30 '11 at 19:18
1

Does each server have it's own version of List locally cached or do you plan to use a centralized caching layer?

As suggested, you can have a centralized "push" process which works off a centralized queue. Any changes submitted by any server are en-queued, and the "push" process can push updates to all the servers via some remoting / WebService mechanism.

This offers the advantage of any changes/updates/deletes being applied at once (or close in time) to all the servers, centralized validation or logging if needed. This also solves the problem of multiple updates - the latest one takes precedence.

I've seen this implemented as a windows service which has an internal queue (can be persisted to DB async for resiliency) which manages the queue and simply takes items one by one, validates the item, loggs change/content and finally pushes it to local Lists via WebService calls to each web server (servers maintain in-memory list which simply gets updated/added/deleted as needed).

Leon
  • 3,311
  • 23
  • 20
1

There are algorithms that can be used to syncronize Distributed systems.

In your case you need an algorithms that given two events on the system tells you wich one of them happened firts. If you can decide for any two events wich is the first one then all the conflicts could be resolved.

I recommend you to use Lamport Clocks.

Ariel
  • 1,641
  • 1
  • 18
  • 27
0

If you're on a Windows platform, I suggest you take a look at "Windows Server AppFabric", and especially the Caching feature. The name is funky, but I think it's exactly what you're looking for, I quote:

A distributed in-memory cache that provides .NET applications with high-speed access, scale, and high availability to application data.

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298