12

スケーラビリティを考慮してクラウド システムを開発することは、システムが機能境界 (usermgmt、ordermgmt、customermgt など) に沿って REST ベースのサービスに構成され、それぞれが独自の基盤となるデータベースを持ち、負荷に応じて、複数のサービスをスピンアップする可能性があることを意味します。たとえば、ordermgmt サービスのインスタンスです。ordermgmt サービスが (「顧客」に代わって) 注文を追加する要求を処理するとき、customermgmt サービスへの REST 呼び出しを行い、顧客などを検証します...

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

Zookeeper でない場合、より適切な提案はありますか? 私たちは Hibernate を ORM として使用していますが、それについてはあまり経験がなく、1 番目と 2 番目のレベルのキャッシュをサポートしていますが、それらが複数のサービス インスタンス間で分散/複製された方法で機能するかどうかはわかりません。 .

ありがとうスコット

4

2 に答える 2

13

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

Zookeeper は、データベース全体を Java ヒープのメモリに保持します。Java ヒープがギガバイト程度を超えると、gc の一時停止の問題が発生し始めます。Zookeeper ノードは常にハートビートを相互に送信しているため、これは Zookeeper では特に厄介です。ノードが GC でビジー状態である間に十分なハートビートが失われると、リーダー選出がトリガーされ、クラスターが一時的にダウンします。

Zookeeper をキャッシュとして使用する場合のもう 1 つの問題は、Zookeeper クラスター内のすべてのノードが同じデータを持つことです。これは通常、キャッシュには必要ありません。

これらの制限により、それぞれ 8 ギガの RAM を備えた 3 台のサーバーは、約 1 ギガの合計ワーキング セットを処理することができます。memcache を使用するか、他のキャッシング システム Sebastien リストのいずれかを使用することをお勧めします。

于 2012-06-12T02:37:29.563 に答える
4

実際には、Hibernate の L2 キャッシュとして、分散されているかどうかに関係なく、さまざまなテクノロジを設定できます。

  • イーキャッシュ
  • Memcached
  • Jキャッシュ
  • ヘーゼルキャスト
  • インフィニスパン
  • テラコッタ
  • ギガスペース XAP
  • ジェムファイア
  • コヒーレンス

データグリッドと呼ばれる最後のものは通常無料ではなく、l2 キャッシュのためだけにデータグリッド全体が必要だとは思いません。

私はそれを使用したことはありませんが、Zookeeper が分散キャッシュとして使用されるように作られたとは思いません。

于 2012-06-11T21:24:33.350 に答える