How to Replicate a Distributed Cache across the WAN

Web applications today are handling millions of users a day. Even with this high traffic, you have to maintain high performance for your users. To achieve this performance goal, many people are using in-memory distributed cache because it is faster than going to the database. A distributed cache also provides scalability by allowing you to add cache servers at runtime as you need to handle higher transaction load.

This is all good. But, you may need to deploy and run your web applications in multiple data centers. You may do this for a variety of reasons. One is to have a disaster recovery option. In this option, you have one active and one passive data center. If the active data center goes down, the passive data center quickly picks up the traffic without causing any interruptions for the users.

Another reason is to locate data centers closer to your customers especially if they are geographically dispersed. This greatly speeds up the application response time for your users. In this option, you may have two or more active data centers rather than an active-passive data center.

If you have multiple data centers either for handling region specific traffic or for disaster recovery purpose, then you need to replicate your cache across all data centers. This replication is across the WAN and would be very slow due to latency unless you do asynchronous replication.

NCache Banner - Reliable multi-site ASP.NET Session Storage

NCache is an extremely fast in-memory distributed cache that also provides WAN replication for your multi-datacenter needs. With NCache, there is no performance degradation while replicating your cache across the WAN because NCache does it asynchronously.

NCache Bridge Topology maintains an in-memory mirrored queue which has all the cache updates. The Bridge can then apply the same updates to one or more target caches whether they’re active or passive. You can read more about Bridge Topology at WAN Replication Topologies (Bridge)

Now, let’s see how to handle WAN replication of your distributed cache for different scenarios with NCache.

Active-passive datacenters: NCache Bridge Topology can be configured for active-passive replication. The active distributed cache submits cache changes to the Bridge so it can apply it to the passive datacenter cache.

Active-active datacenters: In this scenario, the Bridge has to also handle conflict resolution because both datacenters are active and could be updating the same data. This is called conflict resolution and is discussed later in this blog.

One active, multiple passive datacenters: In this scenario, the active distributed cache submits its changes to the Bridge and from that all changes are replicated to all other backup data centers. No conflict can occur here because all the changes are one-way from one active distributed cache to the passive ones.

Three or more active data centers: In this scenario, there is one central active data center where the Bridge is located. Then, all changes from all data centers are submitted to this central Bridge, which then propagates them to all the other active data centers. Because there are multiple active data centers, you can have conflicts when the same cached item is updated in multiple data centers simultaneously. The Bridge is responsible for handling these conflicts and making sure all data centers are updated with the same data.

You can use any Bridge Topology according to your needs. For example, you may be storing ASP.NET Session State in your distributed cache and these sessions need to be replicated across the WAN to the other data center.

When the same data element/item in multiple distributed caches is updated and submitted to Bridge for replication a conflict occurs. To handle conflicts, NCache adds a timestamp for every operation before submitting it to the Bridge. This is to help the Bridge determine which operation was done last for the “last update win” rule.

NCache also provides you the flexibility to implement your own custom conflict resolver and plug in it with your distributed cache.

Here is an example of a conflict resolver:


public class BridgeConflictResolverImpl : IBridgeConflictResolver
{
   private bool _enableLogging;
   private TextWriter _textLogger;

   // to initialize any parameters if needed.
   public void Init(System.Collections.IDictionary parameters) { ... }

   // To resolve entry on the basis of old and new entries.
   public ConflictResolution Resolve(ProviderBridgeItem oldEntry,
                                     ProviderBridgeItem newEntry)
   {
      ConflictResolution conflictResolution =
                                        new ConflictResolution();
      switch (oldEntry.BridgeItemVersion)
      {
         case BridgeItemVersion.OLD:
              conflictResolution.ResolutionAction =
              ResolutionAction.ReplaceWithNewEntry;
              break;
         case BridgeItemVersion.LATEST:
              conflictResolution.ResolutionAction =
              ResolutionAction.KeepOldEntry;
              break;
         case BridgeItemVersion.SAME:
              if (oldEntry.OpCode == BridgeItemOpCodes.Remove)
              {
                    conflictResolution.ResolutionAction =
                    ResolutionAction.ReplaceWithNewEntry;
              }
              else
              {
                    conflictResolution.ResolutionAction =
                    ResolutionAction.KeepOldEntry;
              }
              break;
      }

      return conflictResolution;
   }

   // To dispose parameters if needed.
   public void Dispose() {...}
}

As you can see, the custom conflict resolver allows you to make content driven decisions about which update should “win”.

In summary, the Bridge Topology allows you to run your applications in multiple data centers without having to worry about your cache getting out of sync with the other location. This ensures that your application will always be up even if one data center goes down or you will be able to re-route traffic to the other data center if one datacenter gets overwhelmed with it.

Download NCache Trial | NCache Details

This entry was posted in Bridge Topology, Distributed Cache, Distributed Cache Replication and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


7 × seven =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>