キャッシュ雪崩
古いキャッシュ無効化するので、まだ新しいキャッシュの間に到達していない：キャッシュ我々は単に以下のように理解することができる雪崩：すべてがキャッシュにアクセスする必要があり、（例えば、我々は同じ有効期限を使用してキャッシュを設定すると、キャッシュの大面積は同時に期限が切れます）データベース、およびCPUとメモリデータベースに多大な圧力を照会する要求は、データベースが深刻なダウンタイムを引き起こす可能性があります。従って、連鎖反応を形成するクラッシュにシステム全体を引き起こします。
Redisのは、通常のキャッシュから取得した次のように、図です。
次のようにキャッシュの無効化モーメント図は次のとおりです。
キャッシュ雪崩ソリューション：
溶液は、最も使用されるロック線、次の擬似コードである場合、その場合には、（1）は、一般的に量は、特に複雑ではありません。
ロックキューはちょうどそれは、システムのスループットを改善しない、データベースへの圧力を緩和します。再建中の高い同時、キーバッファと仮定すると999がブロックされている1000以上の要求である、ロックされました。また、タイムアウトを待つために、ユーザの原因となります、これは問題のための一時的な解決策があります！
注：並行性の問題環境分散ロック・キューイングソリューションは、また、分散ロックの問題が解決することがあり、スレッドがブロックされます、ユーザーエクスペリエンスが悪いです！したがって、真の並行性の高いシナリオでめったにを使用していません！
（2）記録バッファの増加に対応する各データ・キャッシュ・タグのバッファは、キャッシュタグが失敗した場合、データ・キャッシュが更新され、次の擬似コードの例無効です。
説明：
図1に示すように、キャッシュタグ：レコードキャッシュデータの有効期限が切れたかどうか、有効期限トリガー通知であれば、実際のキーキャッシュを更新するためにバックグラウンドで別のスレッド。
図2に示すように、データキャッシュ：倍、実施例よりも長く、そのキャッシュの有効期限のタイムスタンプ：30分のキャッシュタグは、キャッシュデータを60分に設定されています。このように、キャッシュタグキーの有効期限が切れたときに、だけでなく、実際のキャッシュの古いデータは更新後の背景に別のスレッドが完了するまで、新しいキャッシュは戻りません、呼び出し最後に返されます。
ロックやキューの使用は、キャッシュの有効期限フラグの更新を設定したキーの異なるキャッシュの有効期限を設定し、1それぞれが「二次キャッシュ」ソリューションとして知られ、そこに：ソリューションのクラッシュをキャッシュについては、ここでは3つのシナリオを提示興味のある読者は自分で勉強することができます。
第二に、キャッシュの浸透
キャッシュの浸透がないデータベースで、ユーザーのクエリデータを参照し、自然にキャッシュ内には存在しません。キャッシュにないユーザーのクエリでこの結果は、再クエリに毎回データベースを再度、その後、空（2件の引き合いに行わ役に立たないのと等価）を返します。このような要求は、多くの場合、キャッシュヒット率が言及されているキャッシュダイレクトアクセスデータベース、バイパスします。
缓存穿透解决方案：
（1）采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
（2）如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！
把空结果也给缓存起来，这样下次同样的请求就可以直接返回空了，即可以避免当查询的值为空时引起的缓存穿透。同时也可以单独设置个缓存区域存储空值，对要查询的key进行预先校验，然后再放行给后面的正常缓存处理逻辑。
三、缓存预热
缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
缓存预热解决方案：
（1）直接写个缓存刷新页面，上线时手工操作下；
（2）数据量不大，可以在项目启动的时候自动进行加载；
（3）定时刷新缓存；
四、缓存更新
除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
（1）定时去清理过期的缓存；
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。
五、缓存降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
ダウングレードすることができます守るために死に戦わなければならないものを引き出すために;従来のシステムは、ハンサム保存するために駒を失うことはないされているかどうかをカーディングにシステムをダウングレードするには、たとえば、ログレベルの計画を参照することができます：
（1）一般：このよう時折ジッタやネットワークサービスなどの一部のサービスは、自動的にダウングレードし、ライン上でタイムアウトしています。
（2）警告：経時的な成功率の変動の一部のサービス（例えば、95％から100の間）はダウングレード低下、およびアラームを送信する自動または手動とすることができます。
（3）エラー：このような90％以下として入手可能な、またはデータベース接続プールオフフック、またはシステムの突然のサージへの訪問が最大しきい値に耐えることができ、この時間は、自動または手動でダウングレードダウングレードいくつかの場合であってもよいです。
（4）重大なエラー：例えば、特別な理由データエラーのため、緊急時マニュアルダウングレードを必要としているこの時間。