問題タブ [hazelcast]

クラスター化されたデータの配布に Hazelcast を使用しています。インターフェイス MapStore と MapLoader を使用して、データの永続性に関するドキュメントを読みました。これらのインターフェースを実装し、クラス名を hazelcast.xml ファイルに書き込む必要があります。

hazelcast を使用したファイル永続化のためのこれらのインターフェイスの実装例はありますか? ダウンロードして使用できるソースコードまたはjarファイルについて知っている人はいますか?

ありがとう

私はHazelcast2.1とSpring3.1でSpring@Cacheableアノテーションを使用しています。

Hazelcast.getMap（）からの参照ではなく、マップからキャッシュされた値のクローン/コピーを返すことは可能 ですか？

つまり、EhCacheのようなcopyOnRead機能が必要です。EhCacheのドキュメントを参照してください

現在取り組んでいるアプリケーションの分散データ グリッド ソリューションとして Hazelcast を評価しています。Hazelcast は分散クラスター上にセットアップされ、私のアプリケーションは Spring を使用して Hazelcast クライアントを次のように定義します。

Hazelcast ノードのhazelcast.xmlファイルで、必要なすべての構成を使用してマップをセットアップしました。このマップの名前を としましょうmyMap。監視用の Hazelcast webapp (mancenter) を使用すると、このマップが適切に設定されていることがわかります。

アプリケーション側で、Bean に注入されるようにマップを構成する必要があります。私が何かをするなら

そして、フェッチロジックを含む Bean にこのマップを注入しましたが、問題はありません。

MapLoaderただし、キャッシュから欠落しているデータを処理するために、インターフェイスを実装するクラスも作成しました。Maploader私の問題は、これを定義したキャッシュに結び付ける方法がわからないことです。次のようなことを試してみると

hz:mapが最上位要素として使用されている場合 (hz:configたとえば、 内ではなく)、内部要素を指定できないように見えるため、XML 解析エラーが発生します。hz:configこれは、要素を定義する必要があると私に思わせます。hz:configただし、クライアントの要素を定義できるかどうかは、ドキュメントからはあまり明確ではありません。hz:configアプリケーションをクラスターの一部にしたい場合は、使用する必要があるようです。ただし、アプリをクラスターの一部にすることが論理的に正しいかどうかはわかりません。基本的には、データ グリッドのクライアントです。

希望する動作を実現するためにアプリを構成する方法について何か考えはありますか?

ありがとう！

Play フレームワーク 2.0/2.1 (1.2+ ではない) で Hazelcast (できれば 2.1) を使用した人はいますか? 上記のバージョンを使用しようとすると例外が発生します (hazelcast の play install を実行できませんでした - 応答として「無効なキー エラー」が返されました)。私のプロジェクトはhazelcast jarファイルを参照しています-依存関係.ymlファイルにもHazelcastへの参照を追加しようとしましたが、役に立ちませんでした。

1.2 に戻す以外の提案は大歓迎です。他に方法がなければ、1.2 のプレイに戻ります。

ドキュメントでこれを見つけることができませんでした。

hazelcastキャッシュに複雑なオブジェクトがある場合：

僕にできる：

これが可能な場合、@Cachable注釈はSpELを使用することを知っています。どういうわけかプログラムでそれを行うことは可能ですか？

ありがとう、

申し訳ありませんが、負荷分散の初心者です。

分散環境では、処理 (マップ/リデュース) をデータに送信して、結果がローカルで計算されてから集計される傾向がますます強くなっています。

私がやりたいことは、複製ではなく、分割/分散されたデータに適用されます。同じような原則に従って、ユーザー データがキャッシュされているサーバーでユーザー リクエストを送信できるようにしたいと考えています。

埋め込みキャッシュまたはデータグリッドを使用して応答時間を短くする場合、データセットが大きい場合、レプリケーションを避けて分散/パーティション化されたキャッシュを使用する傾向があります。

パーティショニング アルゴリズムは一般にハッシュ ベースであり、レプリカを使用してサーバーの障害を処理することができます。

最後に、ユーザー データは通常、3 台のサーバー (プライマリ コピー 1 台とレプリカ 2 台) などでホストされます。

ローカル キャッシュ ミスの場合、キャッシュは通常、他のキャッシュ ピアでエントリを検索できます。これは正常に機能しますが、ネットワーク アクセスが必要です。この無駄なネットワーク呼び出しを回避する負荷分散戦略が必要です。

私が知りたいこと: データが必要な場合、ローカル コピーを持つ Web サーバーの 1 つに常に転送するように、キャッシュのパーティショニング メカニズムを認識しているロード バランサーを使用することは可能ですか?

たとえば、リクエスト www.mywebsite.com/user=387 があります。ロード バランサーは 387 の userId をチェックし、このユーザーがサーバー 1、6、および 12 に格納されていることを認識します。ストラテジー。

一般的なソリューションがない場合、カスタム ルーティング戦略を定義できるオープンソースまたは商用のソフトウェアまたはハードウェア ロード バランサーはありますか?

リクエストのデータをどれだけ抽出すると、ロードバランサーの速度が低下しますか? たとえば、ラウンドロビン戦略と比較して、URLパラメーターを抽出し（user = 387の例のように）、いくつかのルールに従って適切なWebサーバーに移動するコストはいくらですか?

パーティショニング データを簡単に取得してロード バランサーで使用できるようにするために、キャッシュ ベンダーに抽象化ライブラリはありますか?

ありがとう！

ドキュメントの完全なセットを処理するアルゴリズムをサポートする分散型テキスト クラスタリング フレームワークが必要です。キャロット 2 http://project.carrot2.org/のようなアプリケーションは一連のドキュメントで動作し、メモリ内で計算を行うため、時間がかかり、パフォーマンスが非常に効率的です。lingo、STC、knn などのこの種のテキスト クラスタリング アルゴリズムが分散環境で実行できる場合、それらははるかに高速になります。hazelcast http://www.hazelcast.com/のようなオープンソース ツールを使用するフレームワークはありますか、またはより高速でパフォーマンス効率の高い特定のアプローチはありますか。

テラコッタの人たちにとって不公平であることは知っていますが、クラスター化された環境でスケジュールされたジョブを使用するためにHazelcastを使用しようとした人はいますか?

私がイメージできる最も単純な実装は、次のアーキテクチャです。

1. 1 つのサーバーのみが Quartz 構成を起動するようにするためのグローバル Hazelcast ロック。
2. 実際のタスクを DistributedTask として実行します。(これは後で行うことができます。現時点では、重いスケジュールされたタスクが DistributedTask のトリガーを処理する必要があります)
3. ロックを保持しているサーバーがダウンするとすぐに、別のサーバーがロックを取得します。

テラコッタのものを常に開いて開発環境全体の面倒を必要としないため、これはすでにヘーゼルキャストを持っている人にとって大きな利点になると思います.

今のところ、Quartz トリガーの実行を担当するノードを 1 つだけ作成する最も単純なソリューションをコーディングしました。私は Cron のようなトリガーしか使用しないので、負荷の高いトリガー タスク用に DistributedTasks を作成するように注意すれば、許容できる解決策になる可能性があります。

これを実現する org.springframework.scheduling.quartz.SchedulerFactoryBean 拡張機能は次のとおりです。

私が何か大きなものを見逃しているかどうか、そしてこれができるかどうか教えてください.

2 つのファイルを github に追加しました。RAMJobStore 拡張機能は次のとおりです。

https://github.com/mufumbo/quartz-hazelcast/blob/master/src/main/java/com/mufumbo/server/scheduler/hazelcast/HazelcastRAMJobStore.java

Spring SchedulerFactoryBean 拡張機能は次のとおりです。

https://github.com/mufumbo/quartz-hazelcast/blob/master/src/main/java/com/mufumbo/server/scheduler/hazelcast/SchedulerFactoryBean.java

残念ながら、ehcache についてかなり基本的な質問がいくつかあります。重要なインフラストラクチャなしで、クラスター化された Glassfish でキャッシュ メカニズムを使用したいと考えています。私が知っているように、ehcache で分散キャッシュを使用するということは、テラコッタ サーバー アレイを使用する必要があることを意味しますね。

私はキャッシングの経験があまりないので、クラスター化されたグラスフィッシュで ehcache を使用して、JAR を Glassfish のクラスパスに入れるか、WAR などを Glassfish にデプロイできますか? とにかく外部キャッシュサーバーを使用する必要がありますか?

ehcache のレプリケートされたキャッシュには、テラコッタ サーバー アレイは必要ありませんね。

頻繁に変更される Java Map オブジェクトをストアに格納したいと考えています。この場合、私が知っているように、複製されたキャッシュは最良の選択ではありません。Hazelcast 分散キャッシュには外部キャッシュ サーバーが必要ですか? よろしくお願いします！専門家の皆様、良い一日を！

これら 3 つのプロジェクトに頭を悩ませようとしていますが、それらはすべて、クラスタ化しようとしたときに発生するわずかに異なる問題を処理しているようです。しかし、それらのドキュメントはすべて、すでに「よく知っている」開発者向けに書かれており、私のような初心者には理解が難しいものです。

• それぞれが解決しようとしている具体的な問題は何ですか? また、これらの問題は互いにどのように異なるのでしょうか?
• それらのそれぞれを使用したクラスタリングは、アプリ サーバーのクラスタリング (JBoss や GlassFish の組み込みのクラスタリング機能など) とどのように異なりますか?
• これらのフレームワークが解決する問題は、同じプロジェクトでの使用を保証するのに十分なほど異なっていますか? それとも、彼らは互いに競争相手であり、同じ/類似の問題に対して異なる解決策を持っていますか?

これらの好奇心旺盛でありながらとらえどころのないフレームワークについての洞察をお寄せいただきありがとうございます。