Zookeeperはオブジェクトキャッシングに適していますか？

Question

スケーラビリティを重視したクラウドシステムの開発システムは、基本的なデータベースと負荷に応じて、機能境界（usermgmt、ordermgmt、customermgtなど）に沿ってRESTベースのサービスに構成され、スピンする可能性があるordermgmtサービスの複数のインスタンスを起動します。 ordermgmtサービスが注文を追加する要求（「顧客」に代わって）を処理すると、顧客を検証するためにcustomermgmtサービスにREST呼び出しを行います。

カスタマーエンティティは変更されないためZooKeeperのようなものが特定の顧客のインスタンスをキャッシュするのに適しているかどうかは疑問に思っています。これは、customermgmtサービスの複数のインスタンスがデータベースにアクセスする前に問い合わせる可能性があります。私はZookeeperで使用されているさまざまなリストを見てきましたが、オブジェクトキャッシングに使用している人はいません。推奨されているznodeのサイズ（約1K）のように見えます。脱水されたオブジェクトの格納には適していません。また、GCやLRUをサポートしていないので、これも追加する必要があります。

飼い猫がいない場合、より適切な提案はありますか？私たちはORMとしてHibernateを使用していますが、私たちはそれについて多くの経験を持っておらず、第1レベルと第2レベルのキャッシュをサポートしていますが、複数のサービスインスタンスにわたって分散/ 。

おかげ スコットは

Answer 1

実際には、HibernateのL2キャッシュとして、分散型かどうか、多くの異なる技術を、設定することができます。

• EHCacheなど
• Memcachedの
• JCacheの
• Hazelcast
• Infinispan
• テラコッタ
• Gigaspaces XAP
• GemFireの
• コヒーレンス

データグリッドと呼ばれる最後のものは通常無料ではありません.122キャッシュだけではデータグリッド全体が必要ないと思います。

私は決して使っていませんが、私はZookeeperを分散キャッシュとして使用するようには考えていません。

Answer 2

Zookeeperはオブジェクトキャッシュにはあまり適していません。

Zookeeperはデータベース全体をJavaヒープ内のメモリに保持します。 Javaのヒープがギガバイト以上になると、gcの一時停止に関する問題が発生します。これは、飼い猫のノードが常に互いに相手にビートを送り、ノードがビジー状態である間に十分なハートビートが見逃された場合、リーダーの選挙が誘発され、クラスタを間に合わせてしまうため、特に飼い猫にとって厄介です。

zookeeperをキャッシュとして使用する際のもう1つの問題は、Zookeeperクラスタ内のすべてのノードに同じデータ（通常はキャッシュが不要）を持たせることです。

これらの制限により、それぞれ8ギガバイトのRAMを搭載した3台のサーバーは、〜1ギガの総作業セットを処理できます。 memcache、またはSebastienの他のキャッシュシステムの1つを使用する方がよいでしょう。