Redisが既にスタックの一部である場合、MemcachedがRedisと一緒に使用されるのはなぜですか？
Redisは、Memcachedが提供するすべての機能（LRUキャッシュ、アイテムの有効期限、バージョン3.x +でのクラスター化、現在ベータ版）またはtwemproxyなどのツールを使用できます。パフォーマンスも同様です。さらに、Redisは永続性を追加します。これにより、サーバーの再起動時にキャッシュウォーミングを行う必要がなくなります。
RedisとMemcacheを比較するいくつかの古い回答への参照。Memcacheの置き換えとしてRedisを優先するものもあります（スタックに既に存在する場合）：
それにもかかわらず、Instagram、Pinterest、Twitterなどの大規模なWeb規模の企業のスタックを調べたところ、Remをプライマリキャッシングに使用せず、MemcachedとRedisの両方を異なる目的に使用していることがわかりました。一次キャッシュは引き続きMemcachedであり、Redisはデータ構造ベースの論理キャッシュに使用されます。
2014年の時点で、memcachedでできることをすべて実行できるRedisコンポーネントを既に持っているのに、memcachedをスタックに追加コンポーネントとして追加するのに苦労する価値があるのはなぜですか？既存のRedisとは別にmemcachedを含めるようにアーキテクト/エンジニアを傾ける有利な点は何ですか？
更新：
私たちのプラットフォームでは、Memcachedを完全に破棄し、プレーンキャッシュと論理キャッシュの要件にredisを使用しています。高いパフォーマンス、柔軟性、信頼性。
いくつかのシナリオ例：
- キャッシュされたすべてのキーを特定のパターンでリストし、それらの値を読み取りまたは削除します。 redisでは非常に簡単ですが、memcachedでは（簡単に）実行できません。
- Redisで簡単に1 MBを超えるペイロードを保存するには、memcachedでスラブサイズを微調整する必要があります。これには独自のパフォーマンスの副作用があります。
- 現在のキャッシュコンテンツの簡単なスナップショット
- Redisクラスターは、言語ドライバーとともに本番環境にも対応しているため、クラスター化された展開も簡単です。
Redisを介したmemcachedのユースケースとして今日見ている主な理由は、plainHTMLフラグメントキャッシング（または同様のアプリケーション）。オブジェクトの異なるフィールドを異なるmemcachedキーに保存する必要がある場合、Redisハッシュはよりメモリ効率が良くなりますが、多数のキー-> simple_stringペアがある場合、memcachedはより多くのアイテムを提供できるはずですメガバイト。
Memcachedの良い点である他のこと：
- これは非常に単純なコードなので、提供する機能だけが必要な場合は、妥当な代替手段と思いますが、実稼働では使用していません。
- マルチスレッドであるため、シングルボックスのセットアップで拡張する必要がある場合、それは良いことであり、1つのインスタンスだけと話す必要があります。
キャッシュとしてのRedisは、人々がインテリジェントなキャッシングに移行するとき、またはRedisデータ構造を介してキャッシュされたデータの構造を保存しようとするときに、ますます意味があると思います。
Redis LRUとmemcached LRUの比較。
MemcachedとRedisの両方は、実際のLRUエビクションを実行しませんが、その近似のみを実行します。
Memcacheエビクションはサイズごとのクラスであり、そのスラブアロケーターの実装の詳細に依存します。たとえば、特定のサイズクラスに収まるアイテムを追加する場合、memcachedは、そのクラスに関係なく、オブジェクトが何であるかをグローバルに理解しようとする代わりに、そのクラス内の期限切れ/最近使用されていないアイテムを削除しようとしますサイズ。これが最適な候補です。
代わりに、Redisは、サイズクラスに関係なく、maxmemory制限に達したときにすべてのオブジェクトを見て、エビクションの候補として適切なオブジェクトを選択しようとしますが、 より長いアイドル時間を持つ最良のオブジェクト。
Redisがこれを行う方法は、いくつかのオブジェクトをサンプリングし、最も長い間アイドル状態（アクセスされていない）のオブジェクトを選択することです。 Redis 3.0（現在はベータ版）以降、アルゴリズムが改善され、立ち退きにまたがる適切な候補プールが取得されるため、近似が改善されました。 Redisのドキュメントでは、説明とグラフがどのように機能するかについての詳細を見つけることができます 。
単純な文字列->文字列マップについて、memcachedのメモリフットプリントがRedisよりも優れている理由。
Redisはより複雑なソフトウェアです。そのため、Redisの値は、高レベルプログラミング言語のオブジェクトにより似た方法で保存されます。メモリ管理のためのタイプ、エンコード、参照カウントが関連付けられています。これにより、Redisの内部構造は管理しやすくなりますが、文字列のみを処理するmemcachedと比較してオーバーヘッドがあります。
Redisのメモリ効率が向上し始めるとき
Redisは、小さな集約データ型を特別なメモリ節約方法で保存できます。たとえば、オブジェクトを表す小さなRedisハッシュは、ハッシュテーブルではなく、バイナリの一意のblobとして内部に保存されます。したがって、オブジェクトごとに複数のフィールドをハッシュに設定する方が、N個の分離されたキーをmemcachedに保存するよりも効率的です。
実際には、オブジェクトを単一のJSON（またはバイナリエンコード）BLOBとしてmemcachedに保存できますが、Redisとは異なり、独立したフィールドを取得または更新することはできません。
インテリジェントキャッシングのコンテキストにおけるRedisの利点。
Redisデータ構造のため、キャッシュが無効になったときにオブジェクトを破棄し、後でDBから再作成するためにmemcachedで使用される通常のパターンは、Redisを使用する基本的な方法です。
たとえば、サイトの「最新」セクションにデータを入力するために、ハッカーニュースに投稿された最新のNニュースをキャッシュする必要があるとします。 Redisを使用して行うことは、最新のニュースが挿入されたリスト（M個のアイテムに制限付き）を取得することです。データに別のストアを使用し、Redisをキャッシュとして使用する場合は、ビュー（RedisとDB）の両方にbothを設定します新しいアイテムが投稿されます。キャッシュの無効化はありません。
ただし、アプリケーションには常にロジックがあり、Redisリストが空であることがわかった場合、たとえば起動後に、DBから初期ビューを再作成できます。
インテリジェントキャッシングを使用すると、memcachedと比較してより効率的な方法でRedisでキャッシングを実行できますが、すべての問題がこのパターンに適しているわけではありません。たとえば、HTMLフラグメントのキャッシュは、この手法の恩恵を受けない場合があります。
習慣を破るのは難しいです:)
真剣に、2つの主な理由があります-私の理解では-Memcachedがまだ使用されている理由：
- レガシー-Memcachedを使い慣れている開発者と、Memcachedをサポートするアプリケーション。これは、成熟した十分にテストされた技術であることも意味します。
- スケーリング-標準のMemcachedは簡単に水平方向にスケーラブルですが、Redis（間もなくリリースされるv3まで）は、そのためにさらに作業が必要です（シャーディング）。
しかしながら：
- Re。レガシー-Redisの堅牢性（データ構造、コマンド、永続性など）が与えられ、活発に開発されており、考えられるすべての言語のクライアント-新しいアプリケーションは通常それで開発。
- 再スケーリング-今後のv3の他に、スケーリングをはるかに簡単にするソリューションがあります。たとえば、 Redis Cloud は、データの損失やサービスの中断なしにシームレスなスケーリングを提供します。 Redisのスケーリング/シャーディングへのもう1つの一般的なアプローチは、 twemproxy です。