6

FAQの引用を踏まえて、memcached接続を開くことに対処するための効率的なソリューションの提案を探しています。

誤って何度も接続するのを妨げるものは何もないことを忘れないでください。保存しようとしているオブジェクトの一部としてmemcachedクライアントオブジェクトをインスタンス化する場合、1つのリクエストで1,000個のオブジェクトが1,000個の並列接続を作成しても驚かないでください。リストに飛び乗る前に、このようなバグを注意深く探してください。

関連項目：Memcachedクライアントの初期化と接続オブジェクトの管理。

キャッシングアセンブリでシングルトンを使用してmemcachedクライアントを提供することを検討しましたが、ロックによって（不要な？）オーバーヘッドが発生するため、より優れたメソッドが必要になると確信しています。

クライアントの使用パターンについては明確ですが、スケーラビリティとパフォーマンスに関してクライアントを効率的に使用する方法については明確ではありません。他の人はmemcachedクライアントの使用にどのように対処しますか？

あなたのためにそれに50の恵みがあります。

4

1 に答える 1

3

redisクライアントでも同様のシナリオがありました。当初のソリューションは、を介してアクセスを同期する共通の単一インスタンスを用意することでしたlock。これは問題ありませんでしたが、遅延とブロッキングを回避するために、最終的にスレッドセーフなパイプラインクライアントを作成しました。これにより、ブロッキングなしで同時に使用できます。男性の痛みを伴うプロトコルについてはあまり知りませんが、ここで同様のことが当てはまるのではないかと思います。しばらく待つことができれば、これをBookSleeve（カスタムOSS redisクライアント）に追加できるかどうかを調査してみたくなります。

ただし、通常は、同期された共有インスタンスを使用するだけで対応できました（純粋さにもよりますが、シングルトンとほぼ同じです）。

FAQを見ると、パイプラインは確かに可能性があります。そして、 booksleeve内に非同期/パイプライン化されたmemcachedクライアントを作成するオプションを完全に受け入れています。生のIO/多重化のほとんどはredisではかなり一般的です。考えられる他のトリックは、可能な場合は個別のgetではなくget_multiなどを使用することです。ただし、現在のクライアントがこれをサポートしているかどうかはわかりません（IKは調べていません）。

しかし：memcachedとredisの対比はわかりませんが、この場合、パイプライン/多重化APIに切り替えると、多くのプーリング（多くの接続）を使用する必要がなくなりました-単一の接続（適切にパイプライン化された）が可能です単一ノードからの多数の同時使用をサポートします。

于 2011-04-28T16:59:27.817 に答える