質問

RedisはMemcachedが提供するもの（LRUキャッシュ、アイテムの有効期限、そしてバージョン3.x+ではクラスタリング、現在はベータ版）、あるいはtwemproxyのようなツールで提供されるものをすべて行うことができます。パフォーマンスも似ている。さらに、Redisは、サーバーの再起動の際にキャッシュウォーミングを行う必要がないという理由で、永続性を追加します。

RedisとMemcacheを比較した古い回答への参照。そのうちのいくつかは、Memcacheの代替としてRedisを支持しています（スタックにすでに存在する場合）。

• MemcachedとRedisの比較？

• memcachedはRedisに比べれば恐竜のようなものでしょうか？

• RedisとMemcache、それともRedisだけ？

にもかかわらず、Instagram、Pinterest、Twitter などの大規模な Web 企業のスタックを調査したところ、彼らは Memcached と Redis の両方を異なる目的で使用しており、Redis をプライマリ キャッシュに使用していないことが判明しました。プライマリ キャッシュは依然として Memcached であり、Redis はデータ構造ベースの論理キャッシュのために使用されています。

2014年現在、memcachedができることはすべてできるRedisコンポーネントがすでにあるのに、なぜmemcachedはまだスタックに追加コンポーネントとして追加される苦痛に値するのでしょうか？アーキテクトやエンジニアが、既存の Redis とは別に memcached を含めるように促す有利な点は何でしょうか？

更新情報 :

私たちのプラットフォームでは、Memcachedを完全に破棄し、redisをプレーンと論理キャッシュの要件で使用しています。高い パフォーマンス、柔軟性、信頼性に優れています。

いくつかのシナリオの例です。

• 特定のパターンでキャッシュされたすべてのキーをリストアップし、その値を読み取るか削除します。redisでは非常に簡単ですが、memcachedでは（簡単には）できません。
• 1MB以上のペイロードを保存する。redisでは簡単にできるが、memcachedではスラブサイズを調整する必要があり、それ自体がパフォーマンスの副作用を持つ。
• 現在のキャッシュコンテンツの簡単なスナップショット
• Redisクラスタは、言語ドライバとともに本番環境にも対応しており、クラスタ展開も簡単です。

どのように解決するのですか？

私が今日、Redisよりもmemcachedのユースケースとして見ている主な理由は、優れたメモリ効率を得ることができるはずの プレーン HTML フラグメントのキャッシュ (または同様のアプリケーション) で得られるはずの優れたメモリ効率です。オブジェクトの異なるフィールドを異なるmemcachedキーに格納する必要がある場合、Redisハッシュはよりメモリ効率が高くなりますが、多数のキー -> simple_stringペアがある場合、memcachedはメガバイトあたりにより多くのアイテムを提供できるようになるはずです。

その他、memcachedの良いところ。

• 非常にシンプルなコードなので、提供する機能が必要なだけなら、合理的な代替手段だと思いますが、私は本番で使ったことはありません。
• マルチスレッドなので、シングルボックスのセットアップでスケールする必要がある場合は、1つのインスタンスだけで話をする必要があることです。

キャッシュとしてのRedisは、人々がインテリジェントなキャッシュに向かうとき、あるいはRedisのデータ構造を介してキャッシュされたデータの構造を保持しようとするときに、ますます意味をなすと私は信じています。

Redis LRUとmemcached LRUの比較。

memcachedもRedisも本当のLRU evictionsは行わず、その近似値のみを実行します。

memcacheの退去はサイズクラスごとに行われ、そのスラブアロケータの実装の詳細に依存します。たとえば、与えられたサイズ クラスに適合するアイテムを追加したい場合、memcached はそのクラスで期限切れ/最近使用されていないアイテムを削除しようとします。

Redis は、代わりに maxmemory の制限に達したときに、サイズクラスに関係なくすべてのオブジェクトを調べますが、おおよその良いオブジェクトを提供することができるのみで、 を、より大きなアイドルタイムで表示します。

Redisがこれを行う方法は、いくつかのオブジェクトをサンプリングし、最も長い時間アイドル（アクセスされていない）だったものを選ぶことです。Redis 3.0 (現在ベータ版) 以降、アルゴリズムは改良され、また、回避にわたって良い候補プールを取るので、近似値は改善されました。また Redis のドキュメントには、説明とグラフが掲載されています。 .

単純な文字列 -> 文字列マップの場合、memcachedがRedisよりもメモリフットプリントに優れている理由。

Redisはより複雑なソフトウェアなので、Redisの値は高レベルのプログラミング言語におけるオブジェクトに近い方法で保存されます。このため、Redisの内部構造は良好で管理しやすいのですが、文字列のみを扱うmemcachedと比較するとオーバーヘッドがあります。

Redisがよりメモリ効率的になり始めると

Redisは小さなアグリゲートデータタイプを特別に省メモリな方法で保存することができます。例えば、オブジェクトを表す小さなRedisハッシュは、内部的にはハッシュテーブルではなく、バイナリユニークブロブとして保存されます。そのため、オブジェクトごとに複数のフィールドをハッシュに設定すると、N個のキーを分離してmemcachedに保存するよりも効率的です。

実際、オブジェクトを単一のJSON（またはバイナリーエンコード）ブロブとしてmemcachedに格納することはできますが、Redisとは逆に、これでは独立したフィールドをフェッチしたり更新したりすることはできません。

インテリジェントキャッシングのコンテキストにおけるRedisの利点。

Redisのデータ構造のため、キャッシュが無効になった時点でオブジェクトを破棄し、後でDBから再作成するというmemcachedでよく使われるパターンは、Redisを使う原始的な方法と言えます。

たとえば、Hacker Newsに投稿された最新のN個のニュースをキャッシュして、サイトの"Newest"セクションに反映させる必要があるとします。Redisで行うのは、最新ニュースが挿入されたリスト（上限M件）を取得することです。データに別のストアを使用し、Redisをキャッシュとして使用する場合は、次のように入力します。 と を投入します。キャッシュの無効化はありません。

しかし、アプリケーションは常に、例えば起動後にRedisリストが空であることが判明した場合、最初のビューをDBから再作成できるようなロジックを持つことができます。

インテリジェントキャッシュを使用することで、memcachedと比較してより効率的な方法でRedisでキャッシュを実行することが可能ですが、すべての問題がこのパターンに適しているわけではありません。たとえば、HTML フラグメントのキャッシュはこのテクニックの恩恵を受けられないかもしれません。