如何在Azure实例之间共享状态?

时间:2022-01-17 07:10:03

I want to use a global data for MVC web application running on Windows Azure (e.g. something like a list of users having new messages).

我想使用在Windows Azure上运行的MVC Web应用程序的全局数据(例如,具有新消息的用户列表)。

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?

对于普通的webapp,我可以使用一些每appdomain存储,如AppDomain.SetData或只是静态变量。我应该为Azure使用什么(缓存?blob存储?队列?)以及哪种解决方案最快?

4 个解决方案

#1


5  

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.

AppFabric Cache非常适合在角色(或同一角色的实例)之间共享数据。 AppFabric Cache的有趣之处在于它不仅仅适用于ASP.NET会话状态 - 恰好是位于缓存顶端的开箱即用的ASP.NET会话状态提供程序。

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.

将它用作会话状态提供程序需要零代码更改 - 它全部由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.

vtortola对AppFabric Cache在CTP中提出了一个很好的观点,但我们应该看到它在近期的生产中。

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).

由于AppFabric Cache尚未公布定价,这可能会影响您的决定,例如,表存储运行0.15美元/ GB以及相关交易(尽管交易不会对您的成本产生任何明显影响,为0.01美元)每10,000笔交易)。

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

编辑2012年6月7日定价信息自原始答案后发生了变化:

  • The Cache service is in production, and starts at $45 for 128MB (full pricing details here).
  • Cache服务正在生产中,起价为45美元(128MB)(此处为完整定价详情)。
  • 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).
  • 交易现在每100,000交易0.01美元,存储起价为每GB 0.125美元,并根据数量下降(详见此处)。
  • 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).
  • 现在有一个新的缓存功能可以在您的Web或辅助角色实例中启用,使用一定百分比的可用RAM,并且成本为零。您还可以创建独立的缓存角色。全新的SDK v1.7都支持这两种方式。 Scott Guthrie在博客中介绍了新功能(包括Cache)。

#2


8  

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

对于“每用户数据”,您可以使用ASP.Net Session对象。

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

要使Session跨多个角色工作,您需要在web.config中指定跨进程的Session提供程序。微软已经提供了几个示例提供商

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/

对于“全局状态记忆”,我绝对推荐App Fabric Caching或者有一些社区贡献 - 例如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...

如果数据的一致性不重要,那么你总是可以在内存中使用每个实例的缓存 - 这将是最快的路径并且最终会保持一致......

#3


2  

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.

我认为Table Storage可以,但AppFabric缓存服务可能会更合适,具体取决于您的需求,但请记住,最后一个仍然在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.

对于你说的,我会选择桌面存储。执行诸如检索由userId分区并由DateTime键入的表中的最后消息的操作非常快。

Cheers

干杯

#4


1  

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

AppFabric Cache是​​一项过时的服务......对于新开发使用Azure Redis缓存。

#1


5  

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.

AppFabric Cache非常适合在角色(或同一角色的实例)之间共享数据。 AppFabric Cache的有趣之处在于它不仅仅适用于ASP.NET会话状态 - 恰好是位于缓存顶端的开箱即用的ASP.NET会话状态提供程序。

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.

将它用作会话状态提供程序需要零代码更改 - 它全部由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.

vtortola对AppFabric Cache在CTP中提出了一个很好的观点,但我们应该看到它在近期的生产中。

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).

由于AppFabric Cache尚未公布定价,这可能会影响您的决定,例如,表存储运行0.15美元/ GB以及相关交易(尽管交易不会对您的成本产生任何明显影响,为0.01美元)每10,000笔交易)。

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

编辑2012年6月7日定价信息自原始答案后发生了变化:

  • The Cache service is in production, and starts at $45 for 128MB (full pricing details here).
  • Cache服务正在生产中,起价为45美元(128MB)(此处为完整定价详情)。
  • 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).
  • 交易现在每100,000交易0.01美元,存储起价为每GB 0.125美元,并根据数量下降(详见此处)。
  • 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).
  • 现在有一个新的缓存功能可以在您的Web或辅助角色实例中启用,使用一定百分比的可用RAM,并且成本为零。您还可以创建独立的缓存角色。全新的SDK v1.7都支持这两种方式。 Scott Guthrie在博客中介绍了新功能(包括Cache)。

#2


8  

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

对于“每用户数据”,您可以使用ASP.Net Session对象。

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

要使Session跨多个角色工作,您需要在web.config中指定跨进程的Session提供程序。微软已经提供了几个示例提供商

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/

对于“全局状态记忆”,我绝对推荐App Fabric Caching或者有一些社区贡献 - 例如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...

如果数据的一致性不重要,那么你总是可以在内存中使用每个实例的缓存 - 这将是最快的路径并且最终会保持一致......

#3


2  

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.

我认为Table Storage可以,但AppFabric缓存服务可能会更合适,具体取决于您的需求,但请记住,最后一个仍然在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.

对于你说的,我会选择桌面存储。执行诸如检索由userId分区并由DateTime键入的表中的最后消息的操作非常快。

Cheers

干杯

#4


1  

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

AppFabric Cache是​​一项过时的服务......对于新开发使用Azure Redis缓存。