How to share state between Azure instances?

I want to use a global dat开发者_如何学Ca for MVC web application running on Windows Azure (e.g. something like a list of users having new messages).

For a normal webapp, I could use some per-appdomain storage like AppDomain.SetData or just static variable. What should I use for Azure instead (cache? blob storage? queues?) and what solution would be the fastest one?

For "per user data", then you could use the ASP.Net Session object.

To make the Session work across multiple roles, you need to specify a cross-process Session provider in the web.config. Microsoft have provided a couple of example providers already

• one using Table Storage - http://blogs.msdn.com/b/jnak/archive/2009/11/19/using-the-sample-windows-azure-asp-net-providers.aspx

• one more recently using App Fabric Caching - http://convective.wordpress.com/2010/12/18/azure-appfabric-caching-service/

For "global state memory", then I definitely recommend App Fabric Caching or there are a few community contributions - e.g. memcached http://www.davidaiken.com/2011/01/11/windows-azure-memcached-plugin/

If consistency of your data isn't important, then you can always just use per-instance caching in memory - this will be the fastest route and will be eventually consistent...

AppFabric Cache is an excellent fit for sharing data between roles (or instances of the same role). The interesting thing about AppFabric Cache is that it doesn't apply just to ASP.NET Session State - there just happens to be an out-of-the-box ASP.NET Session State Provider that sits atop the cache.

Using the cache is nearly trivial. Here's a snippet from a command-line console app demo:

var dataCacheFactory = new DataCacheFactory();
DataCache dataCache = dataCacheFactory.GetDefaultCache();

Console.Write("Enter a string to cache: ");
string value = Console.ReadLine();

dataCache.Put("key", value);

string response = (string)dataCache.Get("key");
Console.WriteLine("Cached string: " + response);

Using it as a Session State provider requires zero code change - it's all driven by the app.config / web.config.

vtortola makes a good point about the AppFabric Cache being in CTP, but we should see that in production in the near-term.

Table Storage will work as well, depending on the complexity of your queries.It sounds like your queries would be relatively straightforward.

Since pricing hasn't been announced yet for AppFabric Cache, this could factor into your decision vs., say, Table Storage which runs $0.15 / GB plus related transactions (although transactions won't likely have any noticeable impact on your cost, at $0.01 per 10,000 transactions).

EDIT June 7, 2012 Pricing info has changed since original answer:

• The Cache service is in production, and starts at $45 for 128MB (full pricing details here).
• Transactions are now $0.01 per 100,000 transactions, with storage starting at $0.125 per GB and dropping based on quantity (see here for details).
• There's now a new Cache capability that may be enabled within your Web or Worker role instances, using a percentage of available RAM, and costing ZERO. You may also create an independent Cache Role. Both of these are supported with the brand new SDK v1.7. Scott Guthrie blogged about the new features (including Cache).

AppFabric Cache is an outdated service... for new developments use Azure Redis Cache.

I think that Table Storage will do, but maybe AppFabric Caching service would be better fit depending on what you need, but remember this last one is still in CTP.

For what you say, I'll go with table storage. Do something like retrieve last messages in a table partitioned by userId and keyed by DateTime is very fast.

Cheers