3

キャッシュの達人にとってはキャッシュの問題です。

環境

OpenSymphony の OsCache を数年間使用しており、より優れた、より強力な、より高速な、積極的に開発されたキャッシング製品への移行を検討しています。

問題

OsCache の「グループ エントリ」機能を使用しましたが、他の場所では見つかりませんでした。

つまり、OsCache を使用すると、「エントリの挿入時」に 1 つまたは複数のグループを指定できます。後で、各エントリのキーを知らなくても、「エントリのグループ」を無効にすることができます。

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 は大きな助けになります。(たとえば、管理者はボタンを押して、たとえば特定のフォーラムのすべてのキャッシュされた投稿エントリをクリアしたい)

ありがとう

意思

4

1 に答える 1

2

アドホックな無効化プロセスを使用してレガシー システムをスケーリングしようとしたときに、私もマッチャー アプローチを実装しました。キャッシュが小さいため、O(n) の性質は問題ではありませんでした。無効化はユーザーに面していないスレッドで実行され、ロックを保持しなかったため、競合によるペナルティは発生しませんでした。これは、アプリケーション全体に分散されたキャッシュ内の会社のすべてのデータを無効にするなど、キャッシュを横断するキーと照合するために必要でした。これは、デザイン センターが存在しないことが問題でした。そのため、アプリケーションはモノリシックで分解が不十分でした。

ドメイン サービスに基づいて書き直したとき、私は別の戦略を採用しました。構成などの特定のキャッシュに集中化された特定のデータのドメインができたため、マルチルックアップが必要になりました。この場合、キーは値のサブセットにすぎないことがわかったため、ロード後にメタデータ (注釈など) からすべてのキーを抽出できました。これにより、きめ細かなグループ化と、キャッシュの抽象化による便利なプログラミング モデルが可能になりました。私はコア データ構造である IndexMap を、このアイデアに関するチュートリアルで公開しました。抽象化の外で直接使用するためのものではありませんが、直面したグループ化の問題をより適切に解決します。

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

于 2010-07-29T06:49:30.583 に答える