我想知道当前在 Azure AppFabric SDK 中提供的输出缓存提供程序是否支持 (1) 中描述的内容:
通常,当 get 请求失败时,客户端负责
从慢速存储(例如数据库、文件)加载丢失的数据
服务器或远程服务)并填充缓存。这使
请求所需的往返次数并介绍
竞争条件的可能性。开启通读支持
AppFabric 本身会对慢速存储进行二次调用。应用程序结构
通过抽象类的自定义实现获得这种能力
DataCacheStoreProvider。
(3) 的“下一步是什么”部分似乎表明事实并非如此:
此外,Caching会话状态提供者的成功
ASP.NET 的场景导致了对以下功能的请求:
将 write-behind 和 read-through 查询与缓存关联起来,以便
缓存可以成为操作数据的主要方式,同时让
关联的查询更新后端的数据层。
我们将评估这些功能和其他功能是否可能包含在
Windows Azure AppFabric 缓存的未来版本。同时,
我们鼓励您尝试当前的缓存服务
实施并让我们知道它如何为您服务。
是否有任何其他机制可以以编程方式 a)使缓存页面无效和 b)替换缓存页面,而不让它通过客户端请求自然地重新水合(这可能会导致负载下的问题,因为所有请求都竞相重新水合元素)?
与 Windows Server 的其他记录差异 (4):
ASP.NET 缓存
Windows Azure AppFabric 提供会话状态提供程序和
输出缓存提供者。该提供商与发货的提供商不同
与 Windows Server AppFabric 的第一个版本一起。它还提供
附加功能。正因为如此,仔细观察很重要
按照说明正确修改 web.config 文件
适用于 Windows Azure AppFabric。有关详细信息,请参阅使用
AppFabric 的 ASP.NET 4 缓存提供程序。
不可用的缓存功能
Windows Azure AppFabric 支持缓存功能的子集
在 Windows Server AppFabric 中可用。下面的列表描述了
其中一些差异。
通知
Windows Azure AppFabric 缓存不支持通知。
这也意味着您不能使用通知来使
本地缓存。在 Windows Azure AppFabric 中,本地缓存只能使用
基于超时的失效策略。欲了解更多信息
Windows Server AppFabric 中的通知功能,请参阅缓存
通知(Windows Server AppFabric 缓存)。
过期和驱逐
默认情况下,Windows Azure AppFabric 缓存中的项目不会过期。
这意味着当您超过最大缓存大小时,最少
缓存中最近使用的项目将被逐出。与 Windows 服务器不同
AppFabric,无法更改此默认过期设置
或值。但是,如果您使用显式的方式将项目添加到缓存中
过期时间,例如10分钟,那么缓存将遵守这个时间
过期值。这可以通过 Add 的各种重载来完成
和 Put 方法。请注意,ASP.NET 提供程序会自动使用
这些重载为会话状态提供显式超时
输出缓存。
Windows Azure AppFabric 缓存不支持禁用驱逐
一个缓存。在内存压力下,项目总是有可能
被驱逐。应用程序的设计应能够预测这些项目
可能会丢失并需要随时重新加载。如果缓存太多
对于应用程序要求较小,它可以动态地
从 Windows Azure 平台管理门户增加。
有关 Windows Server 中过期和逐出的更多信息
AppFabric,请参阅过期和逐出 (Windows Server AppFabric
缓存)。
高可用性
Windows Azure AppFabric 缓存不支持高可用性
特征。有关 Windows 中高可用性的更多信息
服务器 AppFabric,请参阅高可用性 (Windows Server AppFabric
缓存)。
区域和标签
Windows Azure AppFabric 缓存不支持用户创建的区域
或基于标签的搜索。
API 支持
在大多数情况下,您可以使用相同的 API 来编写缓存客户端
使用 Windows Azure AppFabric 或 Windows Server AppFabric。有
由于两种解决方案之间的差异,存在一些例外情况。对于一个
可用于 Windows Azure AppFabric 的 API 的详细审查
缓存客户端,请参阅API 参考(Windows Azure AppFabric 缓存)。
参考资料:
(1) Windows Server AppFabric 添加了 Read-Through 和 Write-Behind 支持:
http://www.infoq.com/news/2011/08/AppFabric-CTP
(2) ASP.NET 4 的可扩展输出缓存(VS 2010 和 .NET 4.0 系列):
http://weblogs.asp.net/scottgu/archive/2010/01/27/extensible-output-caching-with-asp-net-4-vs-2010-and-net-4- 0-series.aspx
(3) Windows Azure AppFabric 缓存服务简介:
http://msdn.microsoft.com/en-us/magazine/gg983488.aspx
(4) 本地缓存与云端缓存的区别:
http://msdn.microsoft.com/en-us/library/gg185678.aspx
I'm wondering if what's described in (1) is supported by the output caching providers that currently ship in the Azure AppFabric SDK:
Normally when a get request fails the client is responsible for
loading the missing data from slow storage (e.g. a database, file
server, or remote service) and populating the cache. This triples the
number of round-trips needed for the request and introduces the
possibility for a race condition. With Read-Through support turned on
AppFabric itself makes the secondary call to slow storage. AppFabric
gains this ability via a custom implementation of the abstract class
DataCacheStoreProvider.
The "What's Next" section of (3) seems to suggest that it's not:
In addition, the success of the Caching session state provider
scenarios with ASP.NET has resulted in requests for the ability to
associate write-behind and read-through queries with the cache so that
the cache can become the primary way to manipulate data, while letting
the associated queries update the data tier in the back end.
We’ll be evaluating these and other features for possible inclusion in
future releases of Windows Azure AppFabric Caching. In the meantime,
we encourage you to experiment with the current Caching service
implementation and let us know how it works for you.
Is there any other mechanism for programmatically a) invalidating and b) replacing a cached page without letting it naturally re-hydrate through client requests (which can potentially cause issues under load, as all requests race to re-hydrate the element)?
Other documented differences w/ Windows Server (4):
ASP.NET Caching
Windows Azure AppFabric provides both a session state provider and an
output cache provider. This provider differs from the one that shipped
with the first release of Windows Server AppFabric. It also provides
additional features. Because of this, it is important to carefully
follow the instructions for modifying the web.config file correctly
for Windows Azure AppFabric. For more information, see Using the
ASP.NET 4 Caching Providers for AppFabric.
Unavailable Caching Features
Windows Azure AppFabric supports a subset of the caching features
available in Windows Server AppFabric. The following list describes
some of these differences.
Notifications
Notifications are not supported in Windows Azure AppFabric Caching.
This also means that you cannot use notifications to invalidate the
local cache. In Windows Azure AppFabric, local cache can use only a
timeout based invalidation policy. For more information about the
notifications feature in Windows Server AppFabric, see Cache
Notifications (Windows Server AppFabric Caching).
Expiration and Eviction
By default, items in a Windows Azure AppFabric cache do not expire.
This means that when you exceed your maximum cache size, the least
recently used items in the cache are evicted. Unlike Windows Server
AppFabric, there is no way to change this default expiration setting
or value. However, if you add items to the cache with an explicit
expiration time, such as 10 minutes, then the cache will honor this
expiration value. This can be done with various overloads of the Add
and Put methods. Note that the ASP.NET providers automatically use
these overloads to provide explicit timeouts for session state and
output caching.
Windows Azure AppFabric Caching does not support disabling eviction on
a cache. Under memory pressure, it is always possible that items could
be evicted. Applications should be designed to anticipate that items
might be missing and require reloading at any time. If a cache is too
small for the application requirements, it can be dynamically
increased from the Windows Azure Platform Management Portal.
For more information on expiration and eviction in Windows Server
AppFabric, see Expiration and Eviction (Windows Server AppFabric
Caching).
High Availability
Windows Azure AppFabric Caching does not support the high availability
feature. For more information about high availability in Windows
Server AppFabric, see High Availability (Windows Server AppFabric
Caching).
Regions and Tags
Windows Azure AppFabric Caching does not support user-created regions
or tag-based searches.
API Support
In most cases, you can use the same APIs to write cache clients that
use Windows Azure AppFabric or Windows Server AppFabric. There are
some exceptions due to differences between the two solutions. For a
detailed review of the APIs available for Windows Azure AppFabric
cache clients, seeAPI Reference (Windows Azure AppFabric Caching).
References:
(1) Windows Server AppFabric adds Read-Through and Write-Behind Support:
http://www.infoq.com/news/2011/08/AppFabric-CTP
(2) Extensible Output Caching with ASP.NET 4 (VS 2010 and .NET 4.0 Series):
http://weblogs.asp.net/scottgu/archive/2010/01/27/extensible-output-caching-with-asp-net-4-vs-2010-and-net-4-0-series.aspx
(3) Introducing the Windows Azure AppFabric Caching Service:
http://msdn.microsoft.com/en-us/magazine/gg983488.aspx
(4) Differences Between Caching On-Premises and in the Cloud:
http://msdn.microsoft.com/en-us/library/gg185678.aspx
发布评论
评论(1)
正如您引用的文档所示,无法使用 Windows Azure 共享缓存服务(以前称为 Windows Azure AppFabric 缓存)使本地缓存失效。这是因为该服务不支持通知。如果您没有在该服务中使用本地缓存选项,那么您可以通过显式删除缓存项来使其失效。这会将其从服务中的分布式缓存中删除,并且所有请求它的实例将一无所获。
至于替换缓存页面,我相信你可以通过直接更新缓存来做到这一点;然而,考虑到从缓存中删除某些内容时涉及的因素很多,您可能无法 100% 保证页面最终不会因压力而掉落,并且无论如何都会发生竞争。
如果您想要对缓存进行更多控制,我强烈建议您查看新的 Windows Azure 专用缓存预览版。它仍处于预览阶段,因此您可能不想在生产工作中冒险,但它将使您对缓存有更多的控制。
As the document you reference indicates there is no way to invalidate a local cache using Windows Azure Shared Caching Service (previously known as Windows Azure AppFabric Caching). This is because that service does not support notifications. If you are not using the local cache option with that service then you can invalidate a cache items by explicitly removing it. That will remove it from the distributed cache in the service and all instances requesting it would then get nothing.
As for replacing the cached page I believe you could do this by updating the cache directly; however, given the number of factors that go into when something is dropped from the cache you may not be able to 100% guarantee that the page wouldn't eventually fall out due to pressure and the race occur anyway.
If you want a lot more control over the cache I'd highly recommend looking at the new Windows Azure Dedicated Caching preview. It's till in preview, so you may not want to risk it with your production work, but it will give you a LOT more control over your cache.