Redisは、Memcachedが提供するすべてのこと（LRUキャッシュ、アイテムの有効期限、バージョン3.x +でのクラスタリング、現在はベータ版）、またはtwemproxyなどのツールを使用して実行できます。パフォーマンスも同様です。さらに、Redisは永続性を追加するため、サーバーを再起動した場合にキャッシュをウォームアップする必要はありません。

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

• MemcachedとRedis？

• memcachedはRedisと比較して恐竜ですか？

• RedisとMemcacheまたは単にRedis？

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

2014年の時点で、memcachedが実行できるすべてのことを実行できるRedisコンポーネントがすでにあるのに、memcachedをスタックに追加コンポーネントとして追加するだけの価値があるのはなぜですか？アーキテクト/エンジニアが既存のRedisとは別にmemcachedを含めるように傾斜させる有利な点は何ですか？

更新：

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

いくつかのシナリオ例：

• キャッシュされたすべてのキーを特定のパターンで一覧表示し、それらの値を読み取るか削除します。redisでは非常に簡単ですが、memcachedでは（簡単に）実行できません。
• redisで簡単に実行できる1MBを超えるペイロードの保存には、memcachedでのスラブサイズの微調整が必​​要です。これには、独自のパフォーマンスの副作用があります。
• 現在のキャッシュコンテンツの簡単なスナップショット
• Redisクラスターは、言語ドライバーとともに本番環境にも対応しているため、クラスター化されたデプロイも簡単です。

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

memcachedの良い点であるその他のこと：

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

キャッシュとしてのRedisは、人々がインテリジェントキャッシュに移行するとき、またはRedisデータ構造を介してキャッシュされたデータの構造を保持しようとするときに、ますます理にかなっていると思います。

RedisLRUとmemcachedLRUの比較。

memcachedとRedisはどちらも、実際のLRUエビクションを実行しませんが、その近似値のみを実行します。

Memcacheエビクションはサイズごとのクラスであり、スラブアロケーターの実装の詳細に依存します。たとえば、特定のサイズクラスに適合するアイテムを追加する場合、memcachedは、そのクラスの期限切れ/最近使用されていないアイテムを削除しようとします。代わりに、オブジェクトに関係なく、オブジェクトが何であるかをグローバルに理解しようとします。サイズ、これが最適な候補です。

代わりに、Redismaxmemoryは、制限に達したときに、サイズクラスに関係なく、すべてのオブジェクトを調べて、エビクションの候補として適切なオブジェクトを選択しようとしますが、アイドル状態が大きい最良のオブジェクトではなく、ほぼ適切なオブジェクトのみを提供できます。時間。

Redisがこれを行う方法は、いくつかのオブジェクトをサンプリングし、最も長い時間アイドル状態（アクセスされていない）のオブジェクトを選択することです。Redis 3.0（現在ベータ版）以降、アルゴリズムが改善され、エビクション全体で適切な候補プールが取得されるため、近似が改善されました。でRedisのドキュメントあなたはそれがどのように機能するかについての詳細を説明し、グラフを見つけることができます。

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

Redisはより複雑なソフトウェアであるため、Redisの値は、高水準プログラミング言語のオブジェクトに似た方法で保存されます。メモリ管理のために、タイプ、エンコーディング、参照カウントが関連付けられています。これにより、Redisの内部構造は適切で管理しやすくなりますが、文字列のみを処理するmemcachedと比較してオーバーヘッドがあります。

Redisのメモリ効率が向上し始めたとき

Redisは、特別なメモリ節約方法で小さな集計データ型を保存できます。たとえば、オブジェクトを表す小さなRedisハッシュは、ハッシュテーブルではなく、バイナリの一意のblobとして内部に格納されます。したがって、オブジェクトごとに複数のフィールドをハッシュに設定する方が、N個の分離されたキーをmemcachedに格納するよりも効率的です。

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

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

Redisデータ構造のため、キャッシュが無効になったときにオブジェクトを破棄するmemcachedで使用される通常のパターンは、後でDBから再作成するために、Redisを使用する基本的な方法です。

たとえば、サイトの「最新」セクションにデータを入力するために、HackerNewsに投稿された最新のNニュースをキャッシュする必要があるとします。Redisで行うことは、最新のニュースが挿入されたリスト（Mアイテムに制限されている）を取得することです。データに別のストアを使用し、Redisをキャッシュとして使用する場合は、新しいアイテムが投稿されたときに両方のビュー（RedisとDB）にデータを入力します。キャッシュの無効化はありません。

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

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

習慣を破るのは難しいです:)

しかし、真剣に、Memcachedがまだ使用されている理由は2つあります-私の理解では-：

1. レガシー-Memcachedに慣れていて、それをサポートするアプリケーションに精通している開発者がいます。これはまた、それが成熟した十分にテストされた技術であることを意味します。
2. スケーリング-標準のMemcachedは簡単に水平方向にスケーラブルですが、Redis（間もなくリリースされるv3を除く）では、そのためにさらに多くの作業（つまりシャーディング）が必要になります。

しかしながら：

1. 再。レガシー-Redisの堅牢性（データ構造、コマンド、永続性など）を考えると、活発に開発されており、考えられるすべての言語のクライアントがあります-通常、新しいアプリケーションはそれを使用して開発されます。
2. 再スケーリング-今後のv3の他に、スケーリングをはるかに簡単にするソリューションがあります。たとえば、Redis Cloudは、データの損失やサービスの中断なしにシームレスなスケーリングを提供します。Redisのスケーリング/シャーディングに対するもう1つの一般的なアプローチは、twemproxyです。