1

パフォーマンスを最適化するために、(multiGet を使用して) 頻繁に取得される関連するキーを 1 つのサーバー上でグループ化することがベスト プラクティスであるため、これを行うために構築されたクライアント関数によって使用される暗黙的なメカニズムに関していくつか質問があります。

libmemcache (具体的には php-memcached) を使用して同じ目的であると想定しているものを提供するための 2 つの異なるアプローチを見てきました。最初の最も明白なアプローチは、getByKey/setByKey を使用してキーをサーバーにマップすることであり、2 つ目はオプション OPT_PREFIX_KEY を使用することです (memcached::_construct の下の php ドキュメントに投稿された簡単な例があります)。 「アイテムキーの「ドメイン」を作成するために使用されます」. 2 番目のアプローチの注意点は、インスタンスごとにしか設定できないことです。

したがって、私が完全に間違っていない限り、これら 2 つのアプローチは実際には同じ目的を果たしません。他の方法よりもアプローチを使用することの明確な利点はありますか?

そして、私がこのトピックについて話している間、私の他の質問は次のようになります: 一貫してハッシュ化されたシナリオでキーをサーバーにマッピングすることへの影響は、あるとすれば何ですか? ノードに障害が発生した場合、フリーフォーム キーは問題なく新しいサーバーに単純に再マップされると想定しています..

ありがとう！

4

1 に答える 1

0

これらのキーが実際にはほとんど常に一緒に取得される場合は、たとえば、キーを並べ替えて連結し、JSONまたは同様の形式で辞書としてシリアル化された値を格納することにより、単一のキーと値のペアにまとめてキャッシュすることをお勧めします。

あなたの質問に戻る：

  • OPT_PREFIX_KEYは、キーによる値のグループ化とはほとんど関係がなく、この特定のクライアントによって使用されるすべてのキーのプレフィックスを付けるだけなので、「1」は「foo1」になり、「foo」によるグループ化なしで、この新しい値を使用したコンシステントハッシュによって配布されます。
  • getByKey / setByKeyは、libketama（サーバーの選択に使用）とmemcachedサーバーに異なるキーを渡すことができるため、必要なものに最も近い処理を実行します。同じ最初のキーと異なる2番目のキーを指定すると、それらは同じmemcachedサーバーに配置されますが、相互に上書きされることはありません。

時期尚早の最適化はすべての悪の根源です

于 2012-05-18T09:51:43.480 に答える