Redisキャッシュヒット率の向上
転記先:https://www.cnblogs.com/dinglang/p/6117309.html
https://blog.csdn.net/weixin_34238633/article/details/85968131
キャッシュ・ヒット率の説明
ヒット:必要なデータをキャッシュで直接取得できます.
≪ヒットしません｜Do Notヒット｜emdw≫:キャッシュから目的のデータを直接取得することはできません.データベースを再問合せするか、他の操作を実行する必要があります.理由は、キャッシュにまったく存在しないか、キャッシュが期限切れになっているためです.
一般に、キャッシュのヒット率が高いほど、キャッシュを使用する収益が高いほど、アプリケーションのパフォーマンスが良い(応答時間が短いほどスループットが高い)ことを示し、同時性に抵抗する能力が強い.
このことから,高同時性のインターネットシステムでは,キャッシュのヒット率が重要な指標であることが分かる.
キャッシュのヒット率を監視する方法
redisはINFOというコマンドを提供し、いつでもサーバーの状態を監視することができ、telnetから対応するサーバーのポートまで、コマンドを実行すればいい.
出力された情報には、キャッシュのステータスと比較して関係があります.
hitsとmissを計算することで、キャッシュのヒット率を得ることができます:144110/(144110+3228654)=81%、キャッシュの失効メカニズム、および失効時間の設計が良好なシステム、ヒット率は95%以上のruby gemをredis-statと呼び、INFO命令を利用してより直感的な情報レポートを表示することができます.推奨:https://github.com/junegunn/redis-stat
同時に、zabbixは関連するプラグインを提供してredisサービスを監視します.
キャッシュヒット率に影響するいくつかの要因
前の章では、キャッシュヒット率の重要性について説明しましたが、キャッシュヒット率に影響するいくつかの要因を分析します.
1.ビジネスシーンとビジネスニーズ
キャッシュは「読み書きが少ない」ビジネスシーンに適していますが、逆にキャッシュを使用する意味は大きくなく、ヒット率は低いです.
ビジネス要件は、キャッシュの有効期限と更新ポリシーに直接影響する時効性に対する要件を決定します.時効性の要件が低いほど、キャッシュに適しています.同じkeyと同じリクエスト数の場合、キャッシュ時間が長ければ長いほどヒット率が高くなります.
インターネットアプリケーションのほとんどのビジネスシーンでは、キャッシュを使用するのに適しています.
2.キャッシュの設計(粒度と策略)
通常、キャッシュの粒度が小さいほどヒット率が高くなります.実際の例を挙げて説明します.
単一のオブジェクトをキャッシュする場合(たとえば、単一のユーザー情報)、そのオブジェクトに対応するデータが変化した場合にのみ、キャッシュを更新したり、キャッシュを削除したりする必要があります.一方、1つのセットをキャッシュする場合(たとえば、すべてのユーザーデータ)、いずれかのオブジェクトに対応するデータが変化する場合は、キャッシュを更新または削除する必要があります.
もう1つのケースでは、他の場所でもオブジェクトに対応するデータを取得する必要がある場合(例えば、他の場所でも単一のユーザー情報を取得する必要がある場合)、キャッシュが単一のオブジェクトであればキャッシュに直接ヒットすることができ、逆に直接ヒットすることはできません.これにより、より柔軟にキャッシュヒット率が向上します.
また、キャッシュの更新/期限切れポリシーは、キャッシュのヒット率にも直接影響します.データが変化すると、キャッシュを直接更新する値は、キャッシュを削除する(またはキャッシュを期限切れにする)よりもヒット率が高くなります.もちろん、システムの複雑さも高くなります.
3.キャッシュ容量とインフラストラクチャ
キャッシュの容量が限られていると、キャッシュの失効や淘汰を引き起こしやすくなります(現在、多くのキャッシュフレームワークやミドルウェアにLRUアルゴリズムが採用されています).また、キャッシュのテクノロジー選択も重要です.たとえば、アプリケーションに組み込まれたローカルキャッシュを使用すると、シングルマシンのボトルネックが発生しやすくなりますが、分散キャッシュを使用すると拡張しやすくなります.そのため、システム容量の計画を立て、拡張可能かどうかを考慮する必要があります.さらに、キャッシュフレームワークやミドルウェアによって、効率と安定性に差があります.
4.その他の要因
キャッシュノードに障害が発生した場合、キャッシュの失効を回避し、影響を最小限に抑える必要があります.このような特殊な状況も、アーキテクチャ担当者が考慮する必要があります.業界内の比較的典型的なアプローチは、コンシステンシHashアルゴリズム、またはノード冗長性による方法である.
ビジネスニーズがデータの時効性に要求され、キャッシュ時間がキャッシュヒット率に影響を与える以上、システムはキャッシュを使用しないでください.実はこれは重要な要素である同時性を無視しています.通常、同じキャッシュ時間とkeyの場合、キャッシュ時間が短くても、キャッシュの収益は、同時に高いほど高くなります.
キャッシュ・ヒット率を向上させる方法
アーキテクチャの観点から、可能な限りキャッシュによって直接データを取得し、キャッシュの失効を回避する必要があります.これもアーキテクチャの能力を比較的に試すものであり、ビジネスニーズ、キャッシュ粒度、キャッシュポリシー、テクノロジー選択などの各方面でディスク全体を考慮し、バランスをとる必要があります.高周波アクセスで時効性が要求されないホットなビジネス(辞書データ、session、tokenなど)にできるだけ焦点を当て、キャッシュプリロード(予熱)、ストレージ容量の増加、キャッシュ粒度の調整、キャッシュの更新などの手段によりヒット率を向上させる.
時効性が高い(またはキャッシュスペースが限られている)、コンテンツスパンが大きい(またはアクセスがランダムである)、アクセス量が低いアプリケーションではキャッシュヒット率が長期にわたって低い可能性があり、予熱後のキャッシュがアクセスされないうちに期限切れになる可能性があります.
https://blog.csdn.net/weixin_34238633/article/details/85968131
キャッシュ・ヒット率の説明
ヒット:必要なデータをキャッシュで直接取得できます.
≪ヒットしません｜Do Notヒット｜emdw≫:キャッシュから目的のデータを直接取得することはできません.データベースを再問合せするか、他の操作を実行する必要があります.理由は、キャッシュにまったく存在しないか、キャッシュが期限切れになっているためです.
一般に、キャッシュのヒット率が高いほど、キャッシュを使用する収益が高いほど、アプリケーションのパフォーマンスが良い(応答時間が短いほどスループットが高い)ことを示し、同時性に抵抗する能力が強い.
このことから,高同時性のインターネットシステムでは,キャッシュのヒット率が重要な指標であることが分かる.
キャッシュのヒット率を監視する方法
redisはINFOというコマンドを提供し、いつでもサーバーの状態を監視することができ、telnetから対応するサーバーのポートまで、コマンドを実行すればいい.
telnet localhost 6379 info出力された情報には、キャッシュのステータスと比較して関係があります.
keyspace_hits:14414110
keyspace_misses:3228654
used_memory:433264648
expired_keys:1333536
evicted_keys:1547380hitsとmissを計算することで、キャッシュのヒット率を得ることができます:144110/(144110+3228654)=81%、キャッシュの失効メカニズム、および失効時間の設計が良好なシステム、ヒット率は95%以上のruby gemをredis-statと呼び、INFO命令を利用してより直感的な情報レポートを表示することができます.推奨:https://github.com/junegunn/redis-stat
同時に、zabbixは関連するプラグインを提供してredisサービスを監視します.
キャッシュヒット率に影響するいくつかの要因
前の章では、キャッシュヒット率の重要性について説明しましたが、キャッシュヒット率に影響するいくつかの要因を分析します.
1.ビジネスシーンとビジネスニーズ
キャッシュは「読み書きが少ない」ビジネスシーンに適していますが、逆にキャッシュを使用する意味は大きくなく、ヒット率は低いです.
ビジネス要件は、キャッシュの有効期限と更新ポリシーに直接影響する時効性に対する要件を決定します.時効性の要件が低いほど、キャッシュに適しています.同じkeyと同じリクエスト数の場合、キャッシュ時間が長ければ長いほどヒット率が高くなります.
インターネットアプリケーションのほとんどのビジネスシーンでは、キャッシュを使用するのに適しています.
2.キャッシュの設計(粒度と策略)
通常、キャッシュの粒度が小さいほどヒット率が高くなります.実際の例を挙げて説明します.
単一のオブジェクトをキャッシュする場合(たとえば、単一のユーザー情報)、そのオブジェクトに対応するデータが変化した場合にのみ、キャッシュを更新したり、キャッシュを削除したりする必要があります.一方、1つのセットをキャッシュする場合(たとえば、すべてのユーザーデータ)、いずれかのオブジェクトに対応するデータが変化する場合は、キャッシュを更新または削除する必要があります.
もう1つのケースでは、他の場所でもオブジェクトに対応するデータを取得する必要がある場合(例えば、他の場所でも単一のユーザー情報を取得する必要がある場合)、キャッシュが単一のオブジェクトであればキャッシュに直接ヒットすることができ、逆に直接ヒットすることはできません.これにより、より柔軟にキャッシュヒット率が向上します.
また、キャッシュの更新/期限切れポリシーは、キャッシュのヒット率にも直接影響します.データが変化すると、キャッシュを直接更新する値は、キャッシュを削除する(またはキャッシュを期限切れにする)よりもヒット率が高くなります.もちろん、システムの複雑さも高くなります.
3.キャッシュ容量とインフラストラクチャ
キャッシュの容量が限られていると、キャッシュの失効や淘汰を引き起こしやすくなります(現在、多くのキャッシュフレームワークやミドルウェアにLRUアルゴリズムが採用されています).また、キャッシュのテクノロジー選択も重要です.たとえば、アプリケーションに組み込まれたローカルキャッシュを使用すると、シングルマシンのボトルネックが発生しやすくなりますが、分散キャッシュを使用すると拡張しやすくなります.そのため、システム容量の計画を立て、拡張可能かどうかを考慮する必要があります.さらに、キャッシュフレームワークやミドルウェアによって、効率と安定性に差があります.
4.その他の要因
キャッシュノードに障害が発生した場合、キャッシュの失効を回避し、影響を最小限に抑える必要があります.このような特殊な状況も、アーキテクチャ担当者が考慮する必要があります.業界内の比較的典型的なアプローチは、コンシステンシHashアルゴリズム、またはノード冗長性による方法である.
ビジネスニーズがデータの時効性に要求され、キャッシュ時間がキャッシュヒット率に影響を与える以上、システムはキャッシュを使用しないでください.実はこれは重要な要素である同時性を無視しています.通常、同じキャッシュ時間とkeyの場合、キャッシュ時間が短くても、キャッシュの収益は、同時に高いほど高くなります.
キャッシュ・ヒット率を向上させる方法
アーキテクチャの観点から、可能な限りキャッシュによって直接データを取得し、キャッシュの失効を回避する必要があります.これもアーキテクチャの能力を比較的に試すものであり、ビジネスニーズ、キャッシュ粒度、キャッシュポリシー、テクノロジー選択などの各方面でディスク全体を考慮し、バランスをとる必要があります.高周波アクセスで時効性が要求されないホットなビジネス(辞書データ、session、tokenなど)にできるだけ焦点を当て、キャッシュプリロード(予熱)、ストレージ容量の増加、キャッシュ粒度の調整、キャッシュの更新などの手段によりヒット率を向上させる.
時効性が高い(またはキャッシュスペースが限られている)、コンテンツスパンが大きい(またはアクセスがランダムである)、アクセス量が低いアプリケーションではキャッシュヒット率が長期にわたって低い可能性があり、予熱後のキャッシュがアクセスされないうちに期限切れになる可能性があります.