Redis キャッシュを使用する場合

Redis はどのような問題を解決しますか?

#データの大規模な読み取りと執筆とデータベースの読み取り機能の矛盾# CPUキャッシュの開発履歴を振り返るために、 CPU の計算速度とメモリの読み取り速度に応じて、CPU はキャッシュを使用して命令とデータを保存します。 キャッシュは初期のマザーボード キャッシュから現在のレベル 3 キャッシュに進化し、キャッシュ サイズも拡大し続けています。インターネットのデータによると、CPU キャッシュ ヒット率は約 80% です。

コンピュータの開発におけるCPUとメモリの矛盾に類推すると、大規模Webサイトにおける大規模データの読み書きとデータベースの読み書き機能との矛盾も同様であることがわかります。データベースとアプリケーションの間に、データベースよりも高速なストレージ領域、つまりキャッシュを構築することもできます。

Redis がキャッシュとして使用されることは誰もが最もよく知っていますが、Redis の作成者が Redis を設計した当初の意図は、リレーショナル データベースを使用すると、どんなに最適化してもパフォーマンスが向上しないためであったことを私たちは知っています。彼の期待に応えるため、私はメモリ内データベースを手書きで作成しました。

キャッシュの場合、次のようなアプリケーション シナリオがあります:

1. ホットスポット データ たとえば、SQL クエリを保存できます。ユーザーがよく見る画像もメモリに保存できます。

2. ランキング リスト Redis が提供する zset データ構造に基づいて、ランキング リストをより簡単に実装できます。ランキング リストの実装に関する関連コンテンツについては、ランキング アルゴリズムの設計と実装の比較を参照してください。小規模なデータであればMysqlを利用してランキングを実装してもあまり問題はありませんが、データ量が増えると継続的なMysqlの読み書きがボトルネックになってきます。

3. カウンター/速度リミッター
カウンターの適用シナリオの 1 つはユーザーの「いいね！」の数をカウントすることであり、速度リミッターの適用シナリオの 1 つは制限することです。ユーザー IP へのアクセス頻度。 Redis がカウンターに使用できる理由は、Redis がシングルスレッドであるためで、毎回、次の命令が実行される前に前の命令が実行される必要があります。これにより、複数の命令が同時に実行されなくなり、同時実行性の問題が発生しなくなります。スピードリミッターの原理も同様です。

4. 共通の友人
Redis が提供する Set データ構造の交差演算シンターを使用すると、結合テーブル クエリを使用しながら、2 つの Set コレクションの交差をより簡単に見つけることができます。データベース 大規模な Web サイトには膨大な数のユーザーが存在するため、パフォーマンスのオーバーヘッドが大きくなります。

5. シンプルなメッセージ キュー
Redis が提供するパブリッシュ/サブスクライブは、非常にシンプルなメッセージング システムです。 Kafkaのようにトピックやパーティションに分割して永続化する機能はありません。 Redis のメッセージ キューは、高い信頼性を必要としないシナリオで使用されます。

6. セッション共有
セッションは、ユーザーが誰であるかを記録するために使用されます。クラスタを使用してアプリケーションをデプロイする場合、セッションを均一に管理する場所が必要です。データベースを使用してセッションを記録できます。ただし、現時点ではデータベースのパフォーマンス要件が高くなります。また、セッションは通常、時間に敏感です。このロジックはコードに実装する必要がありますが、Redis を使用してセッションを共有すればそのような問題は発生しません。

上記のアプリケーション シナリオの多くは、他のテクノロジを使用して問題を解決することもできますが、特定のリソース制約の下では、Redis などの テクノロジがより良いソリューションとなります。

Redis 関連の技術記事の詳細については、Redis データベースの使用方法のチュートリアル 列にアクセスして学習してください。

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