問題タブ [distributed-caching]

Hazecast と Ehcache の分散キャッシュを評価したい。

まず、標準の dao/service レイヤーを持つ Spring + Hibernate プロジェクトでそれらを使用する方法。Ehcache には、次のような非常にエレガントで使いやすい注釈があります。

Hazelcast の上記のようなものはありますか? エンティティ/dtos に対してそのように Hazelcast を使用する方法に関する情報は見つかりませんでした。

HTTPリクエストを介してタスク処理を提供する必要があるc＃のWebサーバーがあります。バックエンドは他のマシンのサービスバスで動作します。http 経由でタスクを開始すると、タスクがバス経由で送信され、タスクから返されたメッセージが Web サーバーに返されます。

ユーザーが別のマシンでタスクのステータスを要求した場合、開始インスタンスとは異なる Web サーバー インスタンスでバスから受信したメッセージを取得できる必要があります。

クエリ機能を備えたある種の分散キャッシュが必要だと思います...この要件はNoSql分散データベースに似ているようで、おそらくRavenDbが正しい選択になる可能性があります。しかし、RavenDb のコストは、私が必要とするような「メッセージ キャッシュ」には大きいようです。

他にヒントはありますか？

プロジェクトの 1 つで AppFabric キャッシュ機能を使用することを検討しています。分散キャッシュ機能が必要であり、AppFabric が適切なソリューションのようです。ただし、いくつかの質問があり、ここで回答されることを願っています。

Web アプリケーションがインストールされているのと同じマシンで AppFabric キャッシュ サーバーをホストすることを検討しています。MSDN の記事で、AppFabric は専用のマシンにインストールする必要があることがわかりました。また、AppFabric はアプリケーション自体と同じマシンにインストールできますが、いくつかの問題を考慮する必要があることにも注意してください (記事からの引用)。

Windows Server AppFabric キャッシュ ホストは、キャッシュ サービス専用にする必要があります。つまり、これらのサーバーは、アプリケーション、Web、またはデータベース サーバーとしても使用されません。クラスター内で非専用キャッシュ サーバーを使用することは可能ですが、このシナリオはサポートされていません。このポリシーにもかかわらず、非専用のキャッシュ ホストを使用する場合は、各キャッシュ ホストの構成を適切に見積もり、テストして、キャッシュ サービスとマシン上の他のすべてのサービスの両方に十分なメモリとネットワーク リソースを許可するようにしてください。また、他のサービスによるプロセッサとネットワークの使用率が急上昇すると、キャッシュ クラスタのパフォーマンスと安定性に悪影響が及ぶことも理解しておいてください。

この記事へのリンクは次のとおりです:記事 #1

さて、これは十分に理にかなっているように聞こえますが、AppFabric キャッシュが使用できる RAM の量を制限するだけで十分だと考えていました。しかし、MSDN の別の記事を読むと、次のことがわかりました。

物理マシンと仮想マシンの両方について、キャッシュを使用するアプリケーション サーバーまたは Web サーバーに対するキャッシュ クラスターの場所に注意する必要があります。それらが別々のデータ センターにある場合は、それらのデータ センター間の待機時間がパフォーマンスに悪影響を及ぼさないことを確認してください。この段階では、アプリケーションまたは Web サーバーをキャッシュ サーバーとして使用したくなるかもしれません。可能ですが、これはサポートされていません。まず、これらのマシン上の IIS などのサービスによるリソース使用量の急増は、キャッシュ クラスターに影響を与える可能性があります。第 2 に、キャッシュ サービスは専用サーバー上にあると想定し、指定したよりも多くのメモリを使用する可能性があります。

この記事へのリンクは次のとおりです:記事 #2

上記のステートメントを正しく理解していれば、これは、AppFabric の構成設定にもかかわらず、必要なだけの RAM を使用することを意味しますか? これは本当に真実でしょうか？アプリケーションと AppFabric が同じマシンに配置されている構成の経験はありますか?

春のレシピ本を読んでいます。テラコッタについて述べられている特定のことを理解することができません。

以下は本の一節

Terracotta は、目に見える API がなく、変更された状態をクラスター全体のノードに伝達するのにはるかに効率的であるため、現在のほとんどのクラスター化されたキャッシュとは異なります。ほとんどのシステムは、ある種の Java シリアライゼーションまたはブロードキャスト メカニズムを使用します。このメカニズムでは、新しい状態を認識する必要があるかどうかに関係なく、変更されたオブジェクト全体またはオブジェクト グラフが他の各ノードに与えられます。Terracotta はそれを別の方法で行います。オブジェクト グラフ自体のメモリをデルタ化し、オブジェクトの状態の一貫したビューが必要なため、クラスター内の他のノードを同期します。簡潔に言うと、オブジェクト全体ではなく、オブジェクト内の更新された変数を 1 つだけ送信するのと同じようなことを行うことができます。

シリアライゼーションのようなものを使用してクラスター間でオブジェクトを送信しないことは理解できますが、「それはメモリをデルタ化します」とはどういう意味ですか?

そのため、キャッシュするページがいくつかあります。約500万です。

1. ページはめったに更新されません
2. nginxで提供したい
3. サーバーが異なるため、キャッシュにファイルシステムを使用することは不可能です。

いくつかの独立したデータベースまたは NetFS などが必要です。Nginx が静的にサービスを提供するには、可視である必要があり、バックエンドはそのデータベースのキャッシュを制御できます。

現時点ではmongodb gridfsを調べていますが、それが良い選択かどうかはわかりません。そして、不快な制限はほとんどありません。

静的ファイルに最適なスケーラブルなデータベースは?

Terracotta Ehcache (オープン ソース)を使用して、分散トランザクション メモリのベンチマークを実行しようとしています。JTAでの動作を理解するのに問題があります。コードでは、分散トランザクションに関心のあるキャッシュが、JTA を使用して後で 2 フェーズ コミットを実行するリソースとして参加することがわかりました。

私の質問は、1 つのキャッシュのみがリソースとして登録されている場合、JTA が分散設定で他のすべてのキャッシュをアトミックに更新するにはどうすればよいですか? 他のキャッシュ参照を JTA に渡さないため、アトミックな更新は行われません。ここにいくつかの文字列が欠けているように感じます。誰かがそれがどのように機能するか説明できますか? 私も J2EE を初めて使用します。JTA への他のキャッシュの自動参照渡しを可能にする J2EE の概念が欠けていますか?

AppFabricキャッシュは、書き込むキャッシュサーバーをどのように決定しますか？

memcachedのようにコンシステントハッシュを使用していますか？

リクエストURLでキー設定されたHTTP応答（コンテンツ、HTTPヘッダー、タイムスタンプ）を保持（およびキャッシュ）するのに適したPythonのキー/値ストアを探しています。このアプリケーションは、複数のサイトが定期的に照会されるWebスクレイピングエンジンです。次に、一連のルーチンがスクレイピングされたデータを分析します。

これまでに調査したオプションは次のとおりです。

• pythonシェルフモジュール（高速ですが、データを配布できません。単一のプロセスでのみ書き込みます）

• mongodb（比較的高速で、これまでのところ、私が探しているものに最適です）

• couchdb（このアプリケーションには遅すぎます）

• memcached（ストアが永続的ではなく、キャッシュされたデータを複製できないため、適切ではありません。間違っている場合は修正してください）

実際のスクレイピングデータを使用したパフォーマンス結果：

したがって、EhCacheには3つの主要なクラスがあります。

• Cache、
• CacheManager、 と
• Store

複製されたセットアップでは、これらのうち実際に複製されているのはどれですか？キャッシュ、CacheManager、またはストア？Cache'scache(K,V)メソッドを呼び出すと、そのエントリStoreは、それが構成されている基になるもの（メモリ、ディスクなど）に配置されますが、どの複製メカニズムがこのエントリを他の複製メカニズムと同期しますか？

それを理解すると、分散キャッシュを構成したときに、同じ「複製されたメカニズム」がどのように役割を変更するかを理解できるようになります。したがって、次の質問は次のようになります。どのような状況で、分散よりも複製を選択するのでしょうか。分散型は、ずっと強力なオプションのようです。

最後の質問：レプリケーションやディストリビューションはオープンソースのEhCacheディストリビューションで利用できますか？ドキュメントから、EhCacheが「エンタープライズ」という用語を「プロプライエタリ」または「ライセンス」の同義語として使用しているかどうかはわかりません。

N 個の負荷分散サーバー間で分散されるオブジェクトのリストを維持したいと考えています。クライアントが 1 つのサーバーでリストを変更するたびに、これらの変更を他のサーバーに移行したいと考えています。したがって、これはマスター マスター レプリケーションの場合だと思います。これを処理する最も簡単な方法は何ですか? 1 つの単純化された事実は、リスト内のオブジェクトへの各変更には、関連付けられた増加するバージョン番号が関連付けられているということです。そのため、アイテムが 2 つの異なるサーバーで変更され、これら 2 つのデルタが 3 番目のサーバーに移動した場合、競合を解決することができます。

編集: 明確化: 私は Memcached や Redis のような分散型のキー値ストアに精通しています。それはここでは問題ではありません。私が興味を持っているのは、共有リストの競合を解決するメカニズムです。たとえば、サーバー A がリスト内の項目を変更し、サーバー B がその項目を削除した場合、競合をプログラムで解決する方法などです。