現在、2つのアプリサーバーがあり、それぞれにアプリケーションレベルのキャッシュがあり、データベースサーバーが一元化されています。両方のサーバーのアプリキャッシュの同期を維持するために、間にJMSブローカーを設定しました。JMSにメッセージを送信する1つのサーバーのキャッシュクリアでは、他のサーバーが登録されているため、メッセージを取得し、メッセージの内容に基づいて特定のエントリをクリアします。
このメッセージングシステムは、キャッシュエントリをクリアする際に遅延を追加するため、しばらくの間、アプリケーションレベルのキャッシュ間に不整合が生じます。
そこで、すべてのキャッシュの同期を維持するために行われるこの余分な作業をすべて回避するために、集中型キャッシュサーバーを用意することを考えました。
Ehcache / TerracottaまたはHazelcastの使用を検討しています。これらのキャッシュは、結果セット、ロック情報、およびいくつかのシステム固有の変数を保持します。
私たちに最適なキャッシュソリューションを提案してください。
最適な解決策を提案することはおそらくできませんが、いくつかのアイデアを提供しようと思います。
Hazelcast : 非常に使いやすい分散マップを提供します (他にも一見の価値がある多くのものがあります - 分散 SQL クエリは非常に優れています)。
Map<String, Object> map = Hazelcast.getMap("xxx");
これで完了です。標準 API を使用してマップを操作します。Hazelcast の構成/セットアップは非常に簡単です (Ehcache/TC と比較して)。監視 Web アプリも使いやすく便利ですが、不足しているものがあります。小さなクラスター (2 台のサーバーなど) の場合、パフォーマンスは十分なはずです。
Ehcache/Terracotta : セットアップに新しいインフラストラクチャ コンポーネント (Terracotta Server) を導入します - 欠点になる可能性があります。このセットアップを使用することは、私の経験では、学習して試してみるという点で非常に激しいものです. その約束は、エンタープライズ クラス レベルのパフォーマンスと監視機能です。
極端に高いパフォーマンス要件がない場合、私は個人的に Hazelcast を選び、Ehcache/TC の複雑さを回避します。
集中型のMemcachedサーバーを (Hibernate の第 2 レベルのキャッシュおよびその他のキャッシュ要件として) 使用しており、うまく機能しています。XMemcachedクライアントでMemcached を使用していますが、これまでのところ問題なく動作しています。