ヒット: 必要なデータはキャッシュを通じて直接取得できます。
欠落: 必要なデータをキャッシュから直接取得できないため、データベースに再度クエリを実行するか、他の操作を実行する必要があります。理由としては、単純にキャッシュに存在しないか、キャッシュの有効期限が切れていることが考えられます。
一般に、キャッシュ ヒット率が高いほど、キャッシュを使用するメリットが大きくなり、アプリケーションのパフォーマンスが向上し (応答時間が短くなり、スループットが高くなります)、キャッシュに対する耐性が強くなります。同時並行性。
同時実行性の高いインターネット システムでは、キャッシュ ヒット率が重要な指標であることがわかります。
memcached で、state コマンドを実行して memcached サービスのステータス情報を表示します。ここで、cmd_get は get の合計数を表し、get_hits は合計数を表します。ヒット数、ヒット率 = get_hits/cmd_get。
もちろん、オープンソースのサードパーティ ツールを使用して memcached クラスター全体を監視することもでき、表示はより直感的になります。代表的なものには、zabbix、MemAdmin などがあります。
図に示すように: MemAdmin による memcached サービスのヒット率の監視統計
同様に、info を実行できます。 redis のコマンドを使用して、redis サービスのステータス情報を表示します。ここで、keyspace_hits はヒットの合計数、keyspace_misses はミスの合計数、ヒット率 = keyspace_hits/(keyspace_hits keyspace_misses) です。
オープンソース ツール Redis-star は、redis サービス関連の情報をグラフで視覚化することができ、同時に zabbix は、redis サービスを監視するための関連プラグインも提供します。
前の章で、キャッシュ ヒット率の重要性について述べましたが、キャッシュ ヒット率に影響を与えるいくつかの要因を分析してみましょう。
キャッシュは、「読み取りが多く、書き込みが少ない」ビジネス シナリオに適していますが、逆にキャッシュを使用する意義は実際にはありません。素晴らしいです。命中率は非常に低くなります。
ビジネス ニーズによって適時性の要件が決まり、キャッシュの有効期限と更新戦略に直接影響します。適時性の要件が低いほど、キャッシュに適しています。同じキー、同じリクエスト数の場合、キャッシュ時間が長いほどヒット率は高くなります。
キャッシュは、インターネット アプリケーションのほとんどのビジネス シナリオに非常に適しています。
一般に、キャッシュの粒度が小さいほど、ヒット率は高くなります。実際の例を示します。
単一のオブジェクト (例: 単一のユーザー情報) をキャッシュする場合、オブジェクトに対応するデータが変更されたときにキャッシュを更新するか、キャッシュを削除するだけで済みます。コレクション (例: すべてのユーザー データ) をキャッシュする場合、オブジェクトに対応するデータが変更されると、キャッシュを更新または削除する必要があります。
別の状況があり、他の場所でもオブジェクトに対応するデータを取得する必要があると仮定すると (たとえば、他の場所でも個々のユーザー情報を取得する必要がある)、キャッシュが単一のオブジェクトである場合、次のようにすることができます。キャッシュを直接ヒットするか、キャッシュを直接ヒットすることはできません。これはより柔軟であり、キャッシュ ヒット率が高くなります。
さらに、キャッシュ更新/有効期限ポリシーもキャッシュ ヒット率に直接影響します。データが変更された場合、キャッシュされた値を直接更新する方が、キャッシュを削除する (またはキャッシュを期限切れにする) よりもヒット率が高くなりますが、当然、システムの複雑さも高くなります。
キャッシュ容量は限られているため、キャッシュの失敗や削除が容易に発生する可能性があります (現在、ほとんどのキャッシュ フレームワークまたはミドルウェアは LRU アルゴリズムを使用しています)。同時に、キャッシュ テクノロジの選択も重要で、たとえば、アプリケーションに組み込まれたローカル キャッシュを使用すると単一マシンのボトルネックが発生する可能性が高くなりますが、分散キャッシュを使用すると拡張が容易になります。したがって、システム容量を計画し、拡張可能かどうかを検討する必要があります。さらに、キャッシュ フレームワークやミドルウェアが異なれば、効率と安定性も異なります。
キャッシュ ノードに障害が発生した場合は、キャッシュの無効化を回避し、影響を最小限に抑える必要がありますが、アーキテクトはこの特殊な状況も考慮する必要があります。業界における一般的なアプローチは、一貫したハッシュ アルゴリズムまたはノードの冗長性を使用することです。
友人の中には次のような誤解をしている人もいるかもしれません。ビジネス ニーズではデータの適時性に対する高い要件があり、キャッシュ時間はキャッシュ ヒット率に影響するため、システムはキャッシュを使用すべきではありません。実際、これは重要な要素の同時実行性を無視しています。一般に、同じキャッシュ時間とキーの下では、たとえキャッシュ時間が短くても、同時実行性が高くなるほど、キャッシュ収益も高くなります。
アーキテクトの観点から見ると、アプリケーションは可能な限りキャッシュを通じて直接データを取得し、キャッシュの無効化を回避する必要があります。これにはアーキテクトの能力もテストされ、ビジネス要件、キャッシュの粒度、キャッシュ戦略、テクノロジの選択など、さまざまな側面での包括的な考慮とトレードオフが必要になります。頻繁にアクセスされ、適時性の要件が低いホットなサービスにできるだけ重点を置き、キャッシュのプリロード (ウォーミング)、ストレージ容量の増加、キャッシュ粒度の調整、キャッシュの更新を通じてヒット率を向上させます。
高い適時性 (または制限されたキャッシュ スペース)、大きなコンテンツ スパン (または非常にランダムなアクセス)、およびアクセス量の少ないアプリケーションの場合、キャッシュ ヒット率は長期間にわたって非常に低くなる可能性があります。アクセスされる前に。
#Redis 関連の技術記事の詳細については、Redis チュートリアル## 列にアクセスして学習してください。
以上がRedis キャッシュのヒット率を向上させる方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。