内容：
- キャッシュの更新ポリシー
- キャッシュサイズ
- キャッシュの浸透
- キャッシュの雪崩
- キャッシュの内訳
キャッシュ更新戦略：
図1に示すように、メモリのオーバーフロー戦略のうち
Redisのは、より多くのメモリを使用する場合maxmemoryによって適切な戦略をトリガ、具体的な戦略をmaxmemoryポリシー制御パラメータ
6段階的な戦略があります。
）Noeviction：デフォルトポリシーは、このポリシーは、すべてのデータは削除されません。また、クライアントは、メモリ不足（OOM返しを書き込むとき）
）揮発性-LRU：なし削除キー、代替戦略noevicationが存在しない場合はLRUアルゴリズムに従っては、キーの有効期限を削除するように設定されています
）揮発性ランダム：ランダム期限切れのキーを削除
）Allkeys-LRU：LRUアルゴリズムに従って、すべてのキーから削除
）Allkeysランダム：ランダム計算すべてのキー
）揮発性-TTL：フォールバック戦略noevicationがない場合は削除します最近、ttl属性キーを期限切れにすることを目的に応じて、
推奨しないnoevication、allkeys、LRU
2、期限切れのを削除
Redisのは、有効期限辞書有効期限を設定し、専用のストレージを持つクライアントがキーにアクセスしようとするたびに、戻って、有効期限の辞書をチェックし、Ruoyiはnullを返す期限が切れ;しかし、その戦略これだけの削除とします）は、不活性の削除それはまた、いくつかの長期未使用のキーにつながり、このメモリを取るだろう、それは定期的に削除の方針を持っています
）タイミングを外します：内部Redisのは、10秒ごとに1回仕事、デフォルトの実行を維持し、それはキーの割合に基づいて期限切れになり、キー回復速度モードを使用して
3、アプリケーション側を削除
）キャッシュリードを既存の、データ取得は、書き込みキャッシュDBを読んで、読んでいないDB
）キャッシュを削除し、DB（推奨されません）を更新するには、同時書き込み操作の恐怖はダーティデータにつながります
）DBを更新し、キャッシュを削除するには（推奨）
キャッシュサイズ：
最後に、それは全体のオブジェクトキャッシュ、またはデータ・キャッシュは、それを必要としている、我々は二つの側面から分析しました：
1、全体のオブジェクトキャッシュ
長所：優れた汎用性
短所：メモリの浪費、ネットワークトラフィックが、極端な場合には、ネットワークを詰まらせることができ、より大きなシリアライゼーションおよびCPUオーバーヘッドのデシリアライズ
2、データキャッシュのみを使用する必要があります
長所と短所逆に全体のオブジェクトキャッシュのがありますが、キャッシュプロパティを追加するためのコードを変更する必要がありますが、改訂は、キャッシュをリフレッシュする必要があります
キャッシュの浸透：
キャッシュの浸透が存在しないキーにアクセスすることは不可能を意味し、キャッシュ層と永続化層は、圧力永続化層の増加、要求の永続化層への直撃で、その結果、ヒットされません。
その理由は、キャッシュの内訳を表示されます。
彼らのビジネスの問題を達成するための1、
2、悪意のある攻撃、爬虫類など
ソリューション：
1、空のオブジェクトキャッシュ
キャッシュオブジェクトは、二つの質問を持って空：
）より多くのメモリを占有し、バッファ層は、複数のキーを持つことになり、より多くのメモリを必要とすることができます有効期限を設定し、問題を解決するために
）データの矛盾を、キャッシュは、一度に有効である場合、永続データのこの部分を追加した、問題が存在するであろう。によって空のオブジェクトキャッシュMQをクリアするか、さもなければ
図2に示すように、ブルームフィルタ
ブルームフィルタは、実際には、ランダムなバイナリーベクターおよびマッピング機能の非常に長いシリーズです。ブルームフィルタは、以下の場合にセット内の要素を取得するために使用することができます。利点は欠点は、特定のエラー認識率であると難しさを解消し、スペース効率とクエリ時間は一般的なアルゴリズムよりもはるかに多いです。これは、一組の受信キャッシュに層は、記憶層が存在する場合、キーが存在するかどうかに最初のブルームフィルタ検証鍵要求を。
使用するビットマップをブルームフィルタを行います。しかし、このアプローチは、データのためにのみ適してヒットすることはありません高い、比較的固定データ、リアルタイムの低い小型のフットプリントの優位性バッファー;アプリケーションのシナリオは、コードの保守がより複雑です。
キャッシュ雪崩：
我々は、すべてのキャッシュ層が多数の要求は、それが効果的に私たちのDBを保護運ぶことを知っているが、キャッシュ層もあるため、いくつかのケースであってもよくされてダウンしたり、大きなキャッシュを同時に無効化、そしてこれは直接DBに多数の要求につながります、システムが雪崩を引き起こします。
ソリューション：
図1に示すように、高可用性センチネル、クラスタ方式を使用
プロセスのために、二次キャッシュとして、等のRedis 2、マルチレベルキャッシュ、キャッシュシステム
3、ランダムキャッシュの有効期限は、同時にキャッシュの無効化をたくさん聞かせていません
キャッシュの内訳：
ホットキーの有効期限が切れている場合は、単にキーへの同時要求の数が多いが、今回は、DB層へのこれらの同時要求の多くになります。
その理由は、キャッシュの内訳を表示されます。
1、キャッシュはホットキーを持っています
2、キャッシュは、まもなく、このような複雑な計算や複雑なSQLを完了して再構築することはできません
ソリューション：
1、分散ミューテックス
唯一のスレッドがキャッシュを再構築することを可能にする、他のスレッドがする必要があり、キャッシングした後、復興を待つために、実行スレッド、キャッシュからデータを取得します。
2、期限切れになることはありません
ビューレベルのキャッシュの観点から：ホットキーの有効期限を設定しないでください
：ビューレベルの機能性の点から、そのキャッシュを更新するために、別のスレッドを使用して、有効期限は、このロジックを超える場合、ホットキーロジックの有効期限を設定します