缓存模式:您如何称呼(以及如何替换)OpenSymphony OsCache“组”?范例

发布于 2024-09-11 20:36:39 字数 1968 浏览 4 评论 0原文

缓存专家的缓存问题。

上下文

我们已经使用 OpenSymphony 的 OsCache 多年,并考虑转向更好/更强/更快/积极开发的缓存产品。

问题

我们使用了OsCache的“组条目”功能,在其他地方没有发现。

简而言之,OsCache允许您在'entry'处指定一个或多个组 插入时间'。稍后您可以使“条目组”无效,而无需知道每个条目的键。

OsCache 示例

以下是使用此机制的示例代码:

Object[] groups = {"mammal", "Northern Hemisphere", "cloven-feet"}
myCache.put(myKey, myValue , groups );
// later you can flush all 'mammal' entries 
myCache.flushGroup("mammal")
// or flush all 'cloven-foot'
myCache.flushGroup("cloven-foot")

替代方案:匹配器机制

我们使用由前团队成员编写的另一个本地缓存,该缓存使用“关键匹配器”模式使条目无效

在这种方法中,您将定义“键”和匹配器类,如下所示:

public class AnimalKey 
{
   String fRegion;
   String fPhylum;
   String fFootType;

   ..getters and setters go here

}

匹配器:

public class RegionMatcher implements ICacheKeyMatcher
{
   String fRegion;

   public RegionMatcher(String pRegion)
   {
    fRegion=pRegion;
   }

   public boolean isMatch(Obect pKey)
   {
      boolean bMatch=false;
      if (pKey instanceof AnimalKey)
      {
         AnimalKey key = (AninmalKey) pKey);
         bMatch=(fRegion.equals(key.getRegion());
      }
   }
}

用法:

myCache.put(new AnimalKey("North America","mammal", "chews-the-cud");
//remove all entries for 'north america'
IKeyMatcher myMatcher= new AnimalKeyMatcher("North America");
myCache.removeMatching(myMatcher);

该机制实现简单,但具有性能 缺点:它必须遍历每个条目才能使组无效。 (尽管它仍然比旋转数据库更快)。

问题

  • 警告:这可能听起来很愚蠢)您将此功能称为什么? OsCache 将其称为“缓存组”。 JbossCache和EhCache似乎都没有定义也没有实现它。领域?地区?王国?
  • 这种“缓存组/区域”范例是否存在标准模式?
  • 新星缓存产品(例如ehcache、coherence、jbosscache)如何处理这个问题
  • 这个范例不在jcache 规范中,对吧? (JSR-107)
  • 如何处理“大规模失效”?缓存在变得陈旧之前一直都很棒。允许您使大范围无效的 API 是一个很大的帮助。 管理员想要按下按钮并清除特定论坛的所有缓存帖子条目)

谢谢

(例如,

A caching issue for you cache gurus.

Context

We have used OpenSymphony's OsCache for several years and consider moving to a better/stronger/faster/actively-developed caching product.

Problem

We have used OsCache's "group entry" feature and have not found it elsewhere.

In short, OsCache allows you to specify one or more groups at 'entry
insertion time'. Later you can invalidate a "group of entries", without knowing the keys for each entry.

OsCache Example

Here is example code using this mechanism:

Object[] groups = {"mammal", "Northern Hemisphere", "cloven-feet"}
myCache.put(myKey, myValue , groups );
// later you can flush all 'mammal' entries 
myCache.flushGroup("mammal")
// or flush all 'cloven-foot'
myCache.flushGroup("cloven-foot")

Alternative: Matcher Mechanism

We use another home-grown cache written by a former team member which uses a 'key matcher' pattern for invalidating entries

In this approach you would define your 'key' and matcher' class as follows:

public class AnimalKey 
{
   String fRegion;
   String fPhylum;
   String fFootType;

   ..getters and setters go here

}

Matcher:

public class RegionMatcher implements ICacheKeyMatcher
{
   String fRegion;

   public RegionMatcher(String pRegion)
   {
    fRegion=pRegion;
   }

   public boolean isMatch(Obect pKey)
   {
      boolean bMatch=false;
      if (pKey instanceof AnimalKey)
      {
         AnimalKey key = (AninmalKey) pKey);
         bMatch=(fRegion.equals(key.getRegion());
      }
   }
}

Usage:

myCache.put(new AnimalKey("North America","mammal", "chews-the-cud");
//remove all entries for 'north america'
IKeyMatcher myMatcher= new AnimalKeyMatcher("North America");
myCache.removeMatching(myMatcher);

This mechanism has simple implementation, but has a performance
downside: it has to spin through each entry to invalidate a group. (Though it's still faster than spinning through a database).

The question

  • (Warning: this may sound stupid) What do you call this functionality? OsCache calls it "cache groups". Neither JbossCache nor EhCache doesn't seem to neither define nor implement it. Realm? Region? Kingdom?
  • Do standard patterns exist for this "cache groups/region" paradigm?
  • How do rising-star caching products (e.g. ehcache, coherence, jbosscache) handle this problem
  • This paradigm isn't in the jcache spec, right? (JSR-107)
  • How do you handle "mass invalidation"? Caches are great until they grow stale. An API which allows you to invalidate wide swaths is a big help. (E.g. administrator wants to press a button and clear all the cached post entries for, say, a particular forum)

thanks

will

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

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

发布评论

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

评论(1

如痴如狂 2024-09-18 20:36:39

当我尝试使用临时失效流程扩展遗留系统时,我也实现了匹配器方法。 O(n) 性质不是问题,因为缓存很小,失效是在面向非用户的线程上执行的,并且它不持有锁,因此不存在争用惩罚。这是为了匹配横切缓存的键所需要的,例如使分布在应用程序中的缓存中公司的所有数据无效。这实际上是一个没有设计中心的问题,因此应用程序是单一的并且分解得很差。

当我们基于领域服务重写它时,我采用了不同的策略。现在,我们将特定数据的域集中到特定的缓存中,例如配置,因此它成为了多重查找的愿望。在这种情况下,我们意识到键只是值的子集,因此我们可以在加载后从元数据(例如注释)中提取所有键。这允许通过我们的缓存抽象进行细粒度分组和方便的编程模型。我在关于这个想法的教程中发布了核心数据结构 IndexMap。它不适合在抽象之外直接使用,但更好地解决了我们面临的分组问题。

http://code.google.com/p/concurrentlinkedhashmap/wiki/IndexableCache

I too implemented a matcher approach when trying to scale a legacy system with an ad hoc invalidation process. The O(n) nature wasn't a problem since the caches were small, the invalidation was performed on a non-user facing thread, and it didn't hold the locks so there wasn't a contention penalty. This was needed for matching against keys that cross cut caches, such as to invalidate all data for a company in caches spread across the application. This was really a problem of having no design centers so the application was monolithic and poorly decomposed.

When we rewrote it based on domain services, I adopted a different strategy. We now had the domain for specific data centralized into specific caches, such as for configurations, so it became a desire for multi-lookup. In this case we realized that the key was just a subset of the value, so we could extract all of the keys after load from metadata (e.g. annotations). This allowed for fine grained grouping and a convenient programming model through our cache abstraction. I published the core data structure, IndexMap, in a tutorial on the idea. Its not meant for direct usage outside of an abstraction, but better solves the grouping problem we faced.

http://code.google.com/p/concurrentlinkedhashmap/wiki/IndexableCache

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