redisの雪崩、貫通、破壊

      Docker  Nginx、php、mysql、redis         redis    、     
     https://blog.csdn.net/appAndWxy/article/details/113425343

なぜこのような状況を先に書くのか、redis読み書き分離、哨兵、集団などは雪崩、貫通、破壊によるシステム問題を解決したり、迅速に回復したりすることができるが、未然に防ぐべきだ.
キャッシュ雪崩
システムAについては,毎日のピーク時に毎秒5000個のリクエストがあると仮定し,本来はキャッシュがピーク時に毎秒4000個のリクエストを担ぐことができるが,キャッシュマシンが意外にも全体的にダウンタイムした.キャッシュが切れて、この時1秒5000個の要求がすべてデータベースに落ちて、データベースは必然的に担ぐことができなくて、それは警察に通報して、それから掛けました.このとき、この障害を処理する特別な方法がなければ、DBAは焦ってデータベースを再起動したが、データベースはすぐに新しいトラフィックで破壊された.これがキャッシュ雪崩です.
ソリューション:主従+哨兵、ローカルehcacheキャッシュ+hystrix制限フロー&ダウングレード、redis持続化
キャッシュの透過
システムAについては、1秒に5000個の要求があると仮定し、そのうち4000個の要求はハッカーによる悪意のある攻撃である.ハッカーが発行した4000個の攻撃は、キャッシュでは調べられず、データベースに行くたびに調べることもできません.
キャッシュには存在しません.リクエストは毎回「無物にキャッシュ」され、データベースに直接クエリーされます.このような悪意のある攻撃シーンのキャッシュスルーは、データベースを直接殺します.
ソリューション:1.システムAはデータベースから調べられない限り、空の値をキャッシュに書きます.
                  2.IPリクエストの設定現在、同じipの同時および数秒以内のリクエスト数が直接ブラックリストに多すぎます.
キャッシュブレークダウン
あるkeyは非常にホットスポットで、集中的で高同時アクセスの場合、このkeyが失効した瞬間、大量のリクエストがキャッシュを破壊し、データベースを直接要求します.
ソリューション:1.キャッシュされたデータがほとんど更新されない場合は、ホットスポットデータを期限切れに設定してみてください.
                  2.期限が切れる前にキャッシュ値を更新します.
本文献の参考
redisの雪崩、貫通、破壊を知っていて、どのように対応しますか?