Azure 本地缓存与分布式缓存

发布于 2024-12-28 08:43:50 字数 1992 浏览 4 评论 0原文

过去几天我一直在使用 Azure 缓存。好的做法是使用本地缓存功能来防止分布式缓存的往返。

正如可以在文档中读到的那样;当您调用 dataCache.Get(...) 时,应用程序首先检查本地缓存中的版本是否可用,如果不可用,则从分布式缓存中检索对象。 问题在于本地版本可能比对象的分布式版本旧。为了解决这个问题,可以使用“dataCache.GetIfNewer(...)”方法来检查本地对象的版本是否与分布式版本不同,如果不同,则返回新对象。

到目前为止,一切顺利……现在是我的问题;我创建了两个单独的应用程序(应用程序 A 和应用程序 B)来测试 Azure 缓存机制。两个应用程序都运行在两个不同的(物理)位置,因此它们都有自己的本地缓存,但它们都使用相同的分布式缓存。

难道本地缓存失效的过程中真的发生了什么变化吗?我测试了以下场景,发现本地缓存会自动更新:

  • 应用程序 A 使用键“CacheTest”在分布式缓存中存储值“123”
  • 应用程序 B 使用 dataCache.Get(...) 方法检索键“CacheTest”的对象,该对象在本地缓存中找不到,因此从分布式缓存中检索它并返回值为“123”的对象。
  • 应用程序 A 将键为“CacheTest”的对象更改为值“456”
  • 应用程序 B 使用 datacache.Get(...) 方法(再次)检索该对象。因为该对象应该位于本地缓存中,所以我期望值“123”,但它返回新值“456”!

这有多奇怪? Azure 缓存最近是否发生了变化?是的...我确信我已经打开了本地缓存,是的,我已将本地缓存的超时设置为 3600 秒(1 小时)。

有人可以确认 Azure 缓存已更改吗?

尼克的编辑: 那么你的意思是我在荷兰微软网站上找到的下一行代码是无稽之谈?当本地缓存自动更新时,无需调用“GetIfNewer”方法: http://www.dotnetmag.nl/Artikel/1478/Windows-Azure-AppFabric-Caching

/// 
/// Ensures that the newest version of a cached object is returned 
/// from either the local cache or the distrbuted cache.
/// 
public TCachedObjectType GetNewest<TCachedObjectType>(string key) : 
   where TCachedObjectType : class
{
DataCacheItemVersion version;

// Gets cached object from local cache if it exists.
// Otherwise gets cached object from distributed cache and 
// adds it to local cache.
object cachedObject = cache.Get(key, out version); 

// Gets cached object from distributed cached if it is newer
// than given version. 
// If newer it adds it to local cache.
object possiblyNewerCachedObject = 
     cache.GetIfNewer(key, ref version);

if (possiblyNewerCachedObject != null)
{
    // Cached object from distributed cache is newer 
    // than cached object from local cache.
    cachedObject = possiblyNewerCachedObject;
}

return cachedObject as TCachedObjectType;
}

The past days I've been working with Azure Caching. Good practice is to use the local cache functionality to prevent roundtrips to the distributed cache.

As can be read in the documentation; when you make a call to dataCache.Get(...), the application first checks if a version in the local cache is available and, if not, the object is retrieved from the distributed cache.
The problem is that the local version can be older than the distributed version of the object. To solve this problem, the method 'dataCache.GetIfNewer(...)' is available that can be used to check if the version of the local object differs from the distributed version and, if it does, it returns the new object.

So far, so good...now my questions; I've created two seperate applications (app A en app B) to test the Azure Caching mechanism. Both applications run on two different (physical) locations so they both have their own local-cache but they both use the same distributed cache.

Is it true that something has changed in the process of invalidating the local cache? I've tested the following scenario and found out that the local cache is update automatically:

  • App A stores the value "123" in the distributed cache using the key "CacheTest"
  • App B uses the dataCache.Get(...) method to retrieve the object for the key "CacheTest" which cannot be found in the local cache so it is retrieved from the distributed cache en returns the object with value "123".
  • App A changes the object with key "CacheTest" to the value "456"
  • App B uses the datacache.Get(...) method to (again) retrieve the object. Because the object should be in the local cache, I would expect the value "123" but it returns the new value "456"!

How strange is that? Is something changed in Azure Caching lately? And yes...I'm sure that I've turned on local caching and yes, I've set the time-out on the local cache to 3600 seconds (1 hour).

Can somebody confirm that Azure Caching has been changed?

Edit for Nick:
So what you're saying is that the next lines of code that I've found on a Dutch Microsoft site are nonsense? When the local-cache is updated automatically, there's no need to call the 'GetIfNewer' method: http://www.dotnetmag.nl/Artikel/1478/Windows-Azure-AppFabric-Caching

/// 
/// Ensures that the newest version of a cached object is returned 
/// from either the local cache or the distrbuted cache.
/// 
public TCachedObjectType GetNewest<TCachedObjectType>(string key) : 
   where TCachedObjectType : class
{
DataCacheItemVersion version;

// Gets cached object from local cache if it exists.
// Otherwise gets cached object from distributed cache and 
// adds it to local cache.
object cachedObject = cache.Get(key, out version); 

// Gets cached object from distributed cached if it is newer
// than given version. 
// If newer it adds it to local cache.
object possiblyNewerCachedObject = 
     cache.GetIfNewer(key, ref version);

if (possiblyNewerCachedObject != null)
{
    // Cached object from distributed cache is newer 
    // than cached object from local cache.
    cachedObject = possiblyNewerCachedObject;
}

return cachedObject as TCachedObjectType;
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

妳是的陽光 2025-01-04 08:43:50

如果所描述的行为与 appfabric 速度相同,则所描述的行为符合预期。启用本地缓存意味着当给定节点从分布式缓存请求缓存项时,它会询问分布式缓存当前版本是什么。
如果本地缓存的版本与分布式版本匹配,则从本地缓存返回数据。如果没有,则从分布式缓存中检索最新值,缓存在本地然后返回。
这个想法是,如果任何节点更新密钥,即使 appfabric 已经在本地缓存它们,所有节点也将始终确保获得最新版本。分布式缓存跟踪最新版本及其数据的存储位置。

If the described behaviour is the same as appfabric velocity, the behaviour described is as expected. When local caching is enabled it means that when a given node requests a cache item from the distributed cache, it asks the distributed cache what the current version is.
If the locally cached version matches the distributed version, it returns the data from the local cache. If not, it retrieves the latest value from the distributed cache, caches it locally and then returns it.
The idea is that if any node updates the key, all nodes will always be ensured to get the latest version even if appfabric had already cached them locally. The distributed cache keeps track of the latest versions and where their data is stored.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文