Redis を選択する場合

1. 複雑なデータ構造の場合は、redis を選択する方が適切です

値がハッシュ、リスト、セット、順序付きセットなどの複雑なデータ構造の場合、 mc ではこれらのニーズを満たすことができないため、redis が選択されます。

最も一般的なシナリオには、ユーザー注文リスト、ユーザー メッセージ、投稿コメント リストなどが含まれます。

2. 永続性、redis の方が適切です

mc は永続性の要件を満たすことができないため、redis を選択する必要があります。ただし、注意すべき点は、Redis の永続化機能を正しく使用していることを本当に確認したかということです。

redis をデータベースとして使用しないでください:

• Redis の定期的なスナップショットでは、データが失われないことを保証できません;

• Redis の AOF は効率を低下させ、大きすぎるデータをサポートできません;

Redis がソリッド ストレージ内で mysql よりも優れたパフォーマンスを発揮するとは期待しないでください。さまざまなツールが機能します。 Redis をデータベースとして使用するのはおそらく間違っています。

キャッシュ シナリオでは、修復機能を有効にすることのメリットとデメリットは何ですか?

単なるキャッシュ シナリオの場合、データはデータベースに保存され、redis にキャッシュされます。この時点で修復機能をオンにします。

利点は、redis がハングして再起動した後、データベースに瞬時に負荷をかけることなく、ホット データをメモリ内に迅速に復元でき、キャッシュの予熱がないことです。プロセス。

欠点は、redis のハング処理中にデータベース内のデータが変更された場合、redis の再起動後にデータベースと redis データの不整合が発生する可能性があることです。

したがって、読み取り専用シナリオの場合、または一部の一貫性のないビジネス シナリオを許可する場合は、redis の固定化機能を有効にしてみることができます。

3. 高可用性、redis を選択するのがより適切です

redis はクラスター機能を当然サポートしており、アクティブ レプリケーションと読み取り/書き込み分離を実現できます。

Redis は、マスター/スレーブ サービスの監視と自動フェイルオーバーを実現できるセンチネル クラスター管理ツールも公式に提供しており、これらはすべて、プログラムの変更や手動介入を必要とせず、クライアントに対して透過的です。

ナレーション: Memcache で高可用性を実現するには、クライアント側での二重読み取りと二重書き込み、またはサーバー側でのクラスター同期などの二次開発が必要です。

ただし、ここで思い出していただきたいのは、ほとんどのビジネス シナリオでは、キャッシュの可用性を高める必要は本当にあるのでしょうか?

• キャッシュ シナリオでは、キャッシュ ミスが発生します。許可されることが多い;

• キャッシュがダウンしており、DB 経由でデータを読み取ることができることがよくあります;

したがって、慎重に分析する必要があります。ビジネス シナリオ、高可用性、およびそれが真実かどうか キャッシュに対する主な需要は何ですか?

ボイスオーバー: インスタント メッセージング ビジネスでは、ユーザーのオンライン ステータスに高可用性の要件があります。

4. 格納されたコンテンツは比較的大きいため、redis を選択する方が適切です。

memcache の値のストレージは最大 1M です。格納された値の場合、非常に大きいため、redis のみを使用できます。

もちろん、memcache と比較すると、基礎となる実装メカニズムの違いにより、redis にはいくつかの「欠点」もあります。

シナリオ 1: メモリ割り当てメカニズムの違いにより、redis がメモリの断片化を引き起こす可能性がある

memcache は事前に割り当てられたメモリ プールを使用してメモリを管理し、メモリを節約できます。割り当て時間。

Redis はスペースを一時的に適用するため、断片化が発生する可能性があります。

ここからはmcの方が早くなります。

シナリオ 2: 仮想メモリの使用量の違いにより、redis がディスクをフラッシュし、パフォーマンスに影響を与える可能性があります

memcache はすべてのデータを物理メモリに保存します。

Redis には独自の VM メカニズムがあり、理論的には物理メモリよりも多くのデータを保存できます。データが超過すると、スワップがトリガーされ、コールド データがディスクにフラッシュされます。ここからはデータ量が多い場合はmcの方が高速になります。

ナレーション: Redis の新しいバージョンが最適化されました。

ケース 3: ネットワーク モデルの違いにより、redis は CPU 計算により IO スケジューリングに影響を与える可能性があります

memcache はノンブロッキング IO 多重化モデルを使用し、redis もノンブロッキング IO 再利用モデルを使用します。

しかし、redis は KV ストレージ以外のソートおよび集計機能も提供しているため、これらの機能を実行すると、複雑な CPU 計算によって IO スケジューリング全体がブロックされてしまいます。

ここからは、redis の方がより多くの機能を提供するため、mc の方が高速になります。

シナリオ 4: スレッド モデルの違いにより、Redis がマルチコアの特殊効果を使用してパフォーマンスを向上させるのは困難です

memcache はマルチスレッドを使用します。メインスレッドがリッスンし、ワーカーのサブスレッドがリクエストを受け入れて実行します。読み取りおよび書き込み中に、ロックの競合が発生する可能性があります。

Redis はシングルスレッドを使用するため、ロックの競合はありませんが、マルチコアの特性を利用して全体のスループットを向上させるのは困難です。

ここからはmcの方が早くなります。

シナリオ 5: 自動シャーディングがないため、redis は手動でのみ水平方向に拡張できます

redis であっても memcache であっても、サーバー クラスターは自然には拡張されません。クライアントはシャーディングを実行しますが、これは実際には呼び出し元にとってフレンドリーではありません。サーバークラスタが水平拡張をサポートできれば、さらに完璧です。

最後に、これが多くの人が redis を好む理由の 1 つかもしれません。ソース コードが非常に読みやすく、コードの品質が非常に高いということです。

redis と memcache のソースコードを見てきました。読みやすさという点では、redis がこれまで見た中で最もコードがきれいなソフトウェアです。おそらく他にはないソフトウェアです。単純さが redis の本来の目的なのかもしれませんredis のコンパイルにはconfigure も必要なく、サードパーティのライブラリに依存する必要もなく、make だけで済みます。

memcache のソース コードは、スケーラビリティとマルチシステム互換性を考慮しすぎている可能性があります。コードは明確ではなく、面倒に見えます。

たとえば、ネットワーク IO 部分では、Redis のソース コードは 1 ～ 2 ファイルしか使用できません。MC では libevent を使用します。FD はパイプとスレッドを介して行き来するため、特に簡単です人々を混乱させるため。

以上がRedis を選択する場合の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。