Redisのキャッシュ雪崩
我々はキャッシュをハングアップする場合は、私たちの要求はすべてだったことをその手段は、データベースを実行しました。
データは、すべての要求は、データベース、でもダウンタイムの高いCPUやメモリの負荷、およびその結果のデータベースをチェックさせ、キャッシュ、キャッシュミスまたは同時に大きな領域にロードされていません。
我々は、すべてのRedisは全てのデータがキャッシュされて置くことができないことを知っている（高価で、限られたメモリ）、データの必要性は有効期限を設定するのRedisので、定期的に削除キーを期限切れにする2つの戦略を削除するには、[削除不活性+を使用します。
有効期限の時間が同じキャッシュされたデータを設定されており、この部分のデータはRedisのちょうどすべての光を削除する場合は、この時点でこれらのキャッシュは、データベースに、すべての要求を失敗したと同時に、になります。
これはキャッシュ雪崩です：Redisのは、すべてのデータベース要求を行って、ハングアップ。
キャッシュ雪崩が発生した場合は、サービス全体の麻痺が生じ、当社のデータベースを入れてダウンさせるには可能性があります。
このような雪崩の簡単なプロセスとして：
1、大規模な障害がクラスタのRedis;
2、キャッシュミスが、それでも多数の要求は、MySQLデータベースに転用;
3、大型の不活性化は、MySQLデータベースに転用多数の要求をRedisの;
4、MySQLの量を呼び出します爆発は、すぐにでも直接キャリーダウン、またはことができませんでした;
5、多数のアプリケーションのためにMySQLサーバに依存してサービスをRedisの、この時間はすぐに雪崩クラスタサーバ、および最終的には、ウェブサイトの完全な崩壊に変わります。
キャッシュ雪崩を防ぐためにどのように
大幅にキャッシュを削減するキャッシュは、同時に有効期限が切れるとき、有効期限に加え、ランダムな値に。
このような状況「のRedisがハングアップし、すべてのデータベース要求を行く」、我々は次のようなアイデアを持つことができます。
事件前は、Redisの（マスター・スレーブ・アーキテクチャ+センチネルやRedisのクラスタ）の高可用性を実現ハングのRedisを回避しようとしますこれが起こります。
事件、ケースが本当にハングアップのRedis、我々は（hystrix）の電流制限、ローカルキャッシュ+を設定することができ、私達のデータベースを回避しようと殺す（あるいは、少なくとも私たちのサービスが正常に動作していることを確認）することでした。
事件の後、永続のRedis、ディスクからデータをロードし、キャッシュデータの高速リカバリ自動的に再起動します。
図1に示すように、高可用性は、キャッシュ
層は高度に利用できるように設計されて、障害が個々のノード、個々のマシン、エンジンルーム、ダウンも撮影しても、大面積をキャッシュ防ぐバッファ
キャッシュダウングレード2は、
主にローカルキャッシュ（仮支持体）のようにehcacheを利用することができるが、現在のソース・サービス・アクセス、リソース分離（ヒューズ）、降格などを制限します
トラフィック急増は、サービスの問題がまだいくつかの重要なデータによると、システムが自動的にダウングレードすることができ、サービスの可用性を確保する必要があるときは、人工的なダウングレードを達成するためにスイッチを設定することができ、運用、保守を調整するためにそこに設計されます。
目的は、コアダウングレードサービスでも非可逆のために、利用可能であることを確認することです。
個々のニーズその多くの例については、レコメンドサービス、個々のニーズを追加するサービスを提供することはできませんが、あなたはホットデータを追加するためにダウングレードすることができ、大きなフロントページの空白は発生しません。
前格下げにシステムを整理するには、例えば：これらのサービスは、これらのサービスは、例えば、への全体的な計画の後に設定するコアインデックスサーバー、とだけでなく、サービス（静的なページ置換などの使用）を提供し、一時的に許可することができないことを（確認する必要があります）コアビジネスであります：（1）
一般：そのような偶発的ジッタやネットワークサービスなどの一部のサービスは、自動的にダウングレードするために、行にタイムアウトし、
警告、（2）一部のサービス成功率の変動を経時的に（例えば、95から100パーセントの間） 。これは、自動または手動でダウングレードをダウングレードすることができます。そして、アラートを送信します。
（3）エラー：このような90％未満として使用することができます。またはデータベース接続プールは、嵐を殴られました。またはビューが突然最大しきい値に耐えることができるシステムにジャンプし、この時間は、状況下で、自動的にまたは手動でダウングレード低下することがあります。
（4）、重大なエラー：例えば、特別な理由データエラーのため、緊急時マニュアルダウングレードを必要としているこの時間。
3、Redisのバックアップと迅速なウォームアップ
（1）は、データのバックアップとリカバリRedisの
高速なキャッシュを予熱（2）
4は、先に運動の
最後に、提案は運動のキャッシング層の後にぐずぐずフロントラインアイテムに残っている、アプリケーションとバックエンドの負荷や、事前に、プレビューのための高可用性を発生する問題を早期に特定することができる問題。
キャッシュ浸透
キャッシュは、キャッシュ・ミスに起因する存在、およびフォールトトレラントを考慮して、データベースのデータがキャッシュに書き込まれていない場合見つけ出す、各データベース要求の欠如につながるれていない特定のクエリデータを貫通するように言及しますデータベースを検索し、それがキャッシュの意味を失いました。
キャッシュの浸透は、たとえば、存在しないクエリデータを参照：いいえキャッシュからヒットをのRedis、あなたがすべきデータ要求に存在していない時間になりますこれは、データがキャッシュに書き込まれていない見つけ、mysqlデータベースからのクエリに必要データベースクエリ結果のキャッシングの浸透に行きます。
ソリューション：
リクエストのパラメータが正当ではないので（すべてのリクエストパラメータが存在しません）。先に傍受の圧縮されたブルームフィルタまたはフィルタを使用することができ、我々はそう。データベース層への不正なリクエストをさせてはいけません。
私たちは、データベースのデータを見つけることができなかったとき、私たちは、キャッシュオブジェクトを空にします移動し、次の時間を要求するように設定されている、あなたはキャッシュから内部を得ることができます。
このケースでは、一般的に空のオブジェクトは、短い有効期限を設定します。
クエリも空のデータベース場合に取得する2番目の時間がキャッシュに値があるが、データベースにアクセスするために続行されません、あなたがキーを設定するために、いくつかの書式設定ルールを設定することができますので、直接、キャッシュに格納されているデフォルト値を設定するには、クエリ、その後、有効期限が切れフィルタアウトする前にキーのルールに準拠していません *
同時並行性キャッシュ
同時本明細書では、複数のクライアントが同時に設定Redisのことをいいます。
まず最初に実装、最初に来、複数のクライアントの同時動作を実行するために設置し、第一の原則は来る、シングルスレッドであるキー原因は、実際には、自分自身をRedisの並行性の問題は、障害物の残りの部分は、当然のことながら、別のソリューションをredis.setにキューに置かれていますそれを1つずつ実行する必要がありますシリアライズ。
キャッシュ・ウォーミング
予熱した後手段は、関連するキャッシュ・データ・キャッシュ・システムに直接ラインシステム、負荷をキャッシュします。
ときに、ユーザーのリクエスト、最初のクエリのデータベースこれには、予熱されるキャッシュされたデータへのユーザー直接アクセスすることを、そして、データ・キャッシュの問題を回避することができます。
ソリューション
1は、直接書き込みキャッシュが手動のオンライン時間の下で、ページを更新する;
2、プロジェクトの開始時に、データの量を自動的にロードすることができ、
目的はラインシステムの正面にある、データがキャッシュにロードされます。
