問題タブ [distributed-caching]

私は、中心にかなり複雑な (ただし、10,00 個のオブジェクトという大規模ではない) オブジェクト モデルを持つクライアント/サーバー アプリケーションを構築しています。複数のクライアントが (Eclipse RCP GUI を介して) モデルを表示する必要がありますが、サーバーはモデルを直接編集できる唯一のノードになります。モデルの編集内容をクライアントに公開したいと考えています。新しいクライアントは、モデルをリクエストし、更新を登録できます。

これはかなり標準的な Model-View-Controller パターンです。

オブジェクト モデルの配布と、モデルへの変更の配布を処理する、優れたオープン ソースのレプリケート キャッシュ ソリューションを提案できる人はいますか? 1 つのフィールドが変更されるたびに完全なモデルを送信するのではなく、「デルタ」をクライアントに送信する必要があります。

また、オブジェクト グラフを複製し、一貫性を維持できるようにする必要があります。たとえば、'Person' オブジェクトがある場合:

キャッシュに 3 人を追加:

そして、「上司の名前:

次のコードは、すべてのノードで「TheBossXX」を返すと予想されます。

言い換えれば、どのオブジェクトが相互に参照しているかを認識し、すべてのノードでそれらの関係を維持するソリューションが必要です。

あなたの提案を聞くことに興味があります。

ニック

nonstrict-read-writeとの本当の違いは何read-writeですか？ehcacheとHibernateのドキュメントを読むことはできますが、私が見る限り、「更新を行う場合は読み取りと書き込みの方が優れている」としか言われていません。物足りない。

次のように構成された、有効期間の長いキャッシュコレクションに問題がある可能性があります。

コレクションが更新されると、更新が発生するノードなどで正確に何が起こりますか？nonstrict-read-writeこことの違いは何read-writeですか？ノードがキャッシュからの古い10分のバージョンを使用する可能性はありますか？

長いタイムアウトと非同期レプリケーションに注意してください。

次のような Windows Server AppFabric SDK にある Microsoft.ApplicationServer.Caching.DataCache オブジェクトの拡張メソッドがあります。

その意図は、開発者が「最初にキャッシュを試してデータをフェッチしてください。キャッシュで使用できない場合は、指定された関数を実行し、次の呼び出し元のために結果をキャッシュに入れ、結果を返す」というコードを記述できるようにすることです。このような：

ロックは、長時間実行される可能性のある関数呼び出しの実行を 1 つのスレッドに制限しますが、同じマシン上の 1 つのプロセス内に限定されます。複数のプロセス/マシンが一度に機能を実行するのを防ぐために、このパターンをどのように拡張してロックを分散させますか?

ご存知かもしれませんが、コンシステント ハッシュは、DHT を扱う場合に優れたアイデアです。主なアイデアは、新しいノードが追加または削除されたときにあまり影響を受けないようにすることです。

元の論文から：

マシンが一連のキャッシュに追加または削除された場合、新しいキャッシュに移動する必要があると予想されるオブジェクトの割合は、キャッシュ間でバランスの取れた負荷を維持するために必要な最小値です。

解決策は素晴らしいですが、鍵の配布がうまくいかないという現象があります。これを解決するために、元のノードのレプリカがランダムに配布されます。そのソリューションは非常にうまく機能します。確認したい場合は、このチャートを見てください。

わかりました、うまくいくようです。しかし、誰も言及していないことを私は考えていました。

1 つのノードが追加 (または削除) されるとどうなりますか? さて、配置されたノードの「前」にあるすべてのキーを再ハッシュする必要があります。これらのキーは「すべて」のキーではないため、それは良いようです。しかし、たとえば 20 個のレプリカを配置することにした場合、20 個のノードで再ハッシュの手間がかかります。

レプリカが少ないと分散が悪化しますが、レプリカが多いと再ハッシュが必要な場合の負担が大きくなります。

この状況に適した解決策は何ですか? 何か不足していますか？

最近、Terracotta で EHCache を使用して、アプリケーション データの分散データ キャッシュを実行し始めました。クライアント ノードにはヒープ用に約 2 GB があり、サーバー ノードには 8 GB があるとします。1日あたり約1.5GBの大量のデータを生成します。

通常、1 つのクライアントは特定の日のデータセット (約 1.5 GB) を使用しますが、サーバーは明らかにそれらすべてを保持する必要があります。

有効期限が機能する方法は、ヒープが大きくなったときの LRU ベースです。したがって、特定の L1 クライアント側のキャッシュが大きくなりすぎた場合 (たとえば、day1 から day2 に切り替えた場合)、L1 から day1 のすべてのデータを追い出すことが期待されます。6 番目のデータセットを取得するときに L2 が大きくなりすぎると、最も古いデータセットが完全に期限切れになります。Time-to-Live や Time-to-Idle の値がどうあるべきかについて、私は特に意見を持っていないので、未設定のままにしています。

それを数日見た後、これが期待どおりに機能しているとは思えません。たとえば、L2 の最大要素数を 4 にしてテストを実行しました。4 つの要素を入力しました。次に、5番目の要素を配置しました。Cache.put() は例外なく返されましたが、直後に同じキーを持つ Cache.get() が null を返しました!

私の質問は、どうすれば EHCache+Terracotta に自分のやりたいこと、または少なくともそれに近いことをさせることができるでしょうか?

.NET WebサイトとVPS（仮想サーバー）の上にあるAPIインターフェイスがあります。どちらもASP.NETキャッシングシステムを使用しています（これは非常に便利で快適です）。重要な場合-APIシステムはいつかWCFに移植されます。

1 VPSから複数VPSに移行する準備をしたい（大きくなった場合）-したがって、分散キャッシュシステムが必要です。

アイデアをいただければ幸いです:)

ありがとう！

I'm looking into hosting a standard Java web app on AWS and the new Elastic Beanstalk (http://aws.amazon.com/elasticbeanstalk/) seems to have most of what we want. The one thing I can't figure out is how to do distributed caching. It seems that AWS doesn't allow multicast discovery of new nodes, so I'm not sure how new nodes started by the auto-scaling process should be integrated into an existing distributed cache. Any suggestions / best practices appreciated.

Update: Ideally this would be a cache local to each application server instance. Best case scenario would be a hibernate level 2 cache config for something like ehcache or terracota.

次の条件を満たすオープンソースの分散型Key-Valueストレージはありますか。

• ほぼリアルタイムのマルチマスターレプリケーション。（タイブレーカーはタイムスタンプに基づいており、これ以上複雑なものはありません）
• 各ノードは、残りのノードから切断されている場合、そのローカルデータを処理できる必要があります（コンシステントハッシュベースのアプローチは実行できません）。
• 予想されるノードの最大数は最大10です。

以下を評価しました。

• memcachedb
• couchdb
• カサンドラ

そして、上記のものがすべての要件を満たしていないことがわかりました。

アプリケーションのメモリ キャッシング システムに membase または redis を使用する予定です。永続キャッシュシステムに最適なのはどれですか?? 人々は、それらの中でどれが最も優れているかを提案できますか?その理由は何ですか? また、redis と membase の比較とベンチマーク。

分散キャッシュのシナリオでは、一般的に、キャッシュに格納されたモノリシック オブジェクトを使用または回避することをお勧めしますか?

私は EAV スキーマに裏打ちされたサービスを使用しているため、データベースからすべてのプライマリ レコードとそれぞれの属性コレクションを取得するときに、EAV によって課せられる認識されたパフォーマンスの低下を最小限に抑えるためにキャッシュを配置しています。サービスの起動時にキャッシュを準備します。

すべての製品について特に頻繁に電話をかけるわけではありません。クライアントは、ローカル キャッシュにオブジェクト マップを最初に入力した後で差分を呼び出します。その差分を実行するために、分散キャッシュは、任意の基準で実行されるデータベース内の個々のレコードへの変更を反映し、差分がクライアントによって要求されたときに変更を処理する必要があります。

最初に考えられたのは、リストまたはディクショナリを使用してレコードを分散キャッシュに格納することでした。コレクション全体を取得し、ローカルでメモリ内で操作または検索し、コレクション全体をキャッシュに戻します。しかし、後になって考えた結果、キャッシュに個々のレコードを入力するというアイデアが生まれました。それぞれのレコードは、キャッシュから個別に取得/更新できるようにキーが設定されています。これにより、すべてのデータを更新する場合、どの方法がより効率的かという疑問が生じました。

Windows Server AppFabric を使用しているため、BulkGet 操作を利用できます。ただし、一括更新の概念はないと思います。

分散キャッシュ オブジェクトのサイズに関する一般的な考え方はありますか? すべてのアイテムに対してより多くのリクエストがあった場合、ネットワーク帯域幅について懸念が生じますが、少なくとも今のところ、すべてのアイテムに対する需要は最小限に抑えられるはずです。

はい、それぞれの方法をテストしてプロファイリングしますが、ここで考慮すべき現在の考え方の範囲外に何かがあるかどうか疑問に思っています.