あなたが知っている、あなたが知らないほど
、このようなポイントが増える 、習慣
テキスト
ハンギングシリーズの前号では、Redisの基本的な知識について触れましたが、まだ読んでいない方はレビューしていただけます。
Ao Bing：「インタビュアーに掛かる」シリーズ-Redisの基本zhuanlan.zhihu.com
私がいることを言及しRedis、私は面接、または実際の開発プロセスキャッシュでいることを信じて雪崩、穿透、击穿それに慣れていないですが、最終的には3の間に違いがあること、聞いたことが満たされていない場合でも、我々はそのようなないようにする方法でなければなりません何が起こったのか、次の犠牲者がいます。
インタビュー開始
大きなお腹を持って格子縞のシャツを着た中年の男性が、傷だらけのマックを持ってやって来て、はげかかった髪を見て、ニマのトップアーキテクトに違いないと思いました！しかし、私たちの胃の中には詩や本があり、私たちは皆無駄です。
少年、Redisがあなたの履歴書に書かれているのを見たので、要点に直行して、いくつかの一般的な大きな問題を直接尋ねましょう。RedisAvalancheを理解していますか？
こんにちは、ハンサムで魅力的なインタビュアーです。現在、eコマースおよびホットスポットデータのホームページがキャッシュされることを理解しています。通常、キャッシュはスケジュールされたタスクによって更新されるか、見つからなかった後に更新されます。スケジュールされたタスクの更新に問題があります。 。
簡単な例を挙げると、すべてのホームページのキーの有効期限が12時間で、正午に更新された場合、ゼロでスパイクアクティビティが発生し、多数のユーザーが殺到します。その時点で1秒あたり6000リクエストがあったとすると、キャッシュはすべてを保持できます。 1秒あたり5000リクエストですが、その時点でキャッシュ内のすべてのキーが無効です。現時点では、毎秒6000件のリクエストがすべてデータベースに分類され、データベースは必然的にそれを処理できなくなり、アラームが報告されます。実際の状況では、DBAは応答せずに直接ハングする場合があります。この時点で、この障害に対処するための特別な解決策がない場合、DBAは非常に心配してデータベースを再起動しますが、データベースは新しいトラフィックによってすぐに強制終了されます。私が理解しているように、これはキャッシュアバランシェです。
我刻意看了下我做过的项目感觉再吊的都不允许这么大的QPS直接打DB去，不过没慢SQL加上分库，大表分表可能还还算能顶，但是跟用了Redis的差距还是很大
同一时间大面积失效，那一瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的，你想想如果打挂的是一个用户服务的库，那其他依赖他的库所有的接口几乎都会报错，如果没做熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂，等你能重启的时候，用户早就睡觉去了，并且对你的产品失去了信心，什么垃圾产品。
インタビュアーは彼の髪に触れました、ええと、それは悪くないです、それでこの状況はどうですか？どのように対処しますか？
キャッシュアバランシェの処理は簡単です。Redisデータをバッチで保存する場合は、各キーの有効期限にランダムな値を追加して、データが同時に広い領域で失敗しないようにします。Redisは依然としてトラフィックであると思います。耐えることができます。
setRedis（Key、value、time + Math.random（）* 10000）;
Redisがクラスターにデプロイされている場合、ホットデータを異なるRedisライブラリに均等に分散することで、すべての障害を回避することもできます。ただし、実稼働環境でクラスターを操作する場合、単一のサービスが単一のRedisシャードに対応します。データの管理を容易にするだけでなく、障害が発生する可能性があるという欠点もあるため、ランダムな障害時間は優れた戦略です。
または、ホットスポットデータを無期限に設定し、更新操作があったときにキャッシュを更新するだけです（たとえば、ホームページ製品が運用と保守によって更新された場合、キャッシュは終了します。有効期限は設定しないでください）。eコマースホームページのデータもこれを使用できます。運用、保険。
キャッシュの浸透と内訳を知っていますか、それらと雪崩の違いについて話していただけますか？
まず、キャッシュの浸透について説明します。キャッシュの浸透とは、キャッシュまたはデータベースにないデータを指し、ユーザーは引き続きリクエストを開始します。データベースのIDは、idなどのように常に1からインクリメントされます。値が-1のデータ、またはIDが非常に大きく存在しないデータ。現時点では、ユーザーはハッカーである可能性が高く、***はデータベースに過度の圧力をかけ、データベースを深刻に破壊します。
自分で購入したAlibabaCloudサービスなど、小規模なスタンドアロンシステムは基本的に郵便配達員で殺すことができます
このように、パラメータを確認しないと、データベースIDが0より大きくなります。常に0未満のパラメータを使用してリクエストします。Redisをバイパスしてデータベースを直接呼び出すことができるたびに、データベースが毎回見つかるとは限りません。この場合、同時実行性の最高点は簡単に崩壊します。
キャッシュの内訳に関しては、これはキャッシュのなだれと少し似ていますが、少し異なります。キャッシュのなだれは、広範囲のキャッシュ障害が原因でDBがクラッシュしました。キャッシュの内訳の違いは、キャッシュの内訳がキーを参照していることです。ホットスポットは常に大きな同時実行性を保持しており、大きな同時実行性はこのポイントへのアクセスに集中します。キーが無効になると、継続的な大きな同時実行性は、そのままのバケットの場合と同様に、キャッシュを破壊し、データベースを直接要求します。アッパーに穴を開けました。
インタビュアーはほっとした表情を見せたのですが、どうやって解決するのでしょうか？
キャッシュペネトレーションについては、ユーザー認証の検証、パラメーターの検証、IDの基本的な検証、ID <= 0の直接インターセプトなどの不正なパラメーターの直接コードリターンなど、インターフェイスレイヤーでの検証を追加します。
ここで言及したいのは、プログラムを開発するときは「不信」の心を持っている必要があるということです。つまり、発信者を信頼しないでください。たとえば、外出するAPIインターフェイスを提供する場合、これらのいくつかのパラメータがあると思います。呼び出し先として、あなたはあなたに電話をかけた人を信用せず、彼があなたにどのパラメーターを渡すかわからないので、考えられるパラメーター条件を考慮して検証する必要があります。簡単な例として、インターフェースはページングクエリですが、ページングパラメータのサイズを制限しません。呼び出し元が一度にInteger.MAX_VALUEをチェックする場合、リクエストに数秒かかり、さらにいくつかの同時実行が必要になります。電話を切るだけですか？それを呼んだのは会社の同僚ですが、それを見つけるのは大変なことですが、それが***または競合他社である場合はどうでしょうか。ダブルイレブンでインターフェースを調整するとどうなるかを言う必要はありません。これは前のリーダーが私に言ったことであり、誰もがそれを理解する必要があると思います。
これにより、***ユーザーが同じIDブルートフォース***を繰り返し使用するのを防ぐことができますが、通常のユーザーが1秒間にそれほど多くのリクエストを開始しないことを知っておく必要があります。また、Nginxのゲートウェイレイヤーに構成アイテムがあることも覚えています。これにより、O＆Mは、1秒あたりのアクセス時間が単一のIPのしきい値を超えるすべてのIPを大幅にブロックできます。
他に方法はありますか？
また、Redisには高度な使用法のBloom Filter（Bloom Filter）もあり、キャッシュの侵入を防ぐことができます。また、彼の原則は、効率的なデータ構造とアルゴリズムを使用してすばやく決定するのも非常に簡単です。キーがデータベースに存在するかどうか、存在しない場合は戻るだけです。存在する場合は、DBを確認し、KVを更新してから、戻ります。
キャッシュから取得できないデータもデータベースに取得されません。このとき、対応するキーの値のペアをnullとして書き込むこともできます。場所が間違っているため、値は後で再試行されます。製品に問い合わせるか、特定の値を確認してください。シーンの場合、キャッシュの有効時間を30秒などの短いポイントに設定できます（設定が長すぎると、通常の状態では使用できなくなります）。
それから何人かの友人は***が同時に多くのIPを持っているなら***を始めると言いましたか？私はこれを理解していませんが、***の一般的なレベルにはそれほど多くのブロイラーがなく、Redisクラスターの通常のレベルはこのレベルのアクセスに抵抗できます。中小企業は興味がないと思います。の。システムの高可用性が完了した後でも、クラスターは非常に機能的です。
キャッシュが壊れている場合、ホットスポットデータが期限切れになることはありません。または、ミューテックスロックを追加して実行します。暖かい人として、私は間違いなくあなたのためにコードを準備します。
/ ***データの取得* @ paramキークエリパラメータ* @ returnデータデータ* @ throws InterruptedException * @author Ao Bing * /
public static String getData（String Key）throws InterruptedException {
// redisからのクエリデータStringresult = getDataByKV （Key）;
//パラメータの検証if（StringUtils.isBlank（result））{
//ロックを取得if（reenLock.tryLock（））{
//データベースに移動して結果をクエリ= getDataByDB（Key）;
//検証するif（ StringUtils.isNotBlank（result））{
//キャッシュに入るsetDataToKV（Key、result）;
}
// !!!ロックを解除します。通常、最終的にreenLock.unLock（）;で解除されます。
} else {
//しばらくスリープして、もう一度取得します。Thread.sleep（100L）;
result = getData（Key）;
}
}
return result;
} //ここでのロックはすべてスタンドアロンプレイ用であり、分散ロックは引き続きluaスクリプトに依存する必要があります。
インタビュー終了
うーん、悪くはありません。3つのポイントすべてが非常によく答えられています。今日は早すぎないので、最初にインタビューを行い、明日戻ってきます。引き続き、Redisクラスターの高可用性、マスタースレーブ同期、センチネルなどについてお聞きします。問題を指摘します。
ハオは実際に次のラウンドのインタビューをしています！（次の号の前兆ははは）しかし、私はまだそれをなめる必要があります、ええと、良いハンサムなインタビュアー。
このように包括的かつ詳細に答えることができれば、仕方がないのですが（好きだということですが、読むたびに好きではありません。無料で歌いたいですか？良いか悪いか、でも好きです⁄（⁄ ⁄•⁄ω⁄） •⁄ ⁄）⁄）
総括する
遊びましょう、遊びましょう、インタビューについて冗談を言ってはいけません。
この記事では、Redisの雪崩、故障、浸透について簡単に紹介します。3つは実際には同じですが、いくつかの違いがあります。インタビューでは、これは実際にはキャッシュについて尋ねる必要があります。3つを混同しないでください。キャッシュのなだれ、浸透、故障はキャッシュの最大の問題であるため、どちらも表示されず、一度表示されると致命的な問題になるため、インタビュアーは間違いなくあなたに尋ねます。
誰もがそれがどのように起こったか、それを回避する方法、そしてそれが起こった後にそれを救う方法を理解する必要があります。あなたはそれを深く知る必要はありませんが、それについて考えることはできません。インタビューは必ずしも知識の苦痛ではありません。多分それはあなたの態度の苦痛です。あなたが明確な心を持っていて、それからあなたが理由を知っているなら、それは素晴らしいことです、そしてあなたはそれが機能するのを防ぐ方法を知っています。
最後に、私はあなたに小さな技術的な要約を与え続けます：
一般に、上記の状況の発生を回避するために、次の3つの期間から分析します。
- 事前に：Redisの高可用性、マスタースレーブ+センチネル、Redisクラスター、完全なクラッシュを回避します。
- イベントの場合：ローカルehcacheキャッシュ+ Hystrixの現在の制限+ MySQLが強制終了されないようにするためのダウングレード。
- イベント後：RedisはRDB + AOFを保持します。再起動すると、ディスクからデータが自動的に読み込まれ、キャッシュされたデータがすばやく復元されます。
- ハンギングシリーズのRedisシリーズで上記の点についてお話します。今月は可能です。Redisは終了しました。現在の制限コンポーネントでは、1秒あたりのリクエスト数、コンポーネントを通過できる数、残りの未通過のリクエストを設定できます。どうすればよいですか？ ？ダウングレードしてください！いくつかのデフォルト値、わかりやすいプロンプト、または空白の値を返すことができます。
利点：
データベースが停止することはなく、現在の制限コンポーネントにより、1秒あたりの要求数のみが通過できるようになります。データベースが停止していない限り、つまりユーザーの場合、リクエストの3/5を処理できます。リクエストの3/5を処理できる限り、システムが停止していないことを意味します。ユーザーの場合、数回クリックするとページが表示されない場合がありますが、数回クリックするとページを1回表示できます。
これは現在の主流のインターネット企業の間で最も一般的です。特定の有名人に何が起こったのか知りたいですか？Weiboに行くとインターフェースが空白になっていることがわかりますが、直接入る人もいます。それは何度か出てきましたが、それはダウングレードであり、サーバーのセキュリティと引き換えに一部のユーザーのエクスペリエンスを犠牲にしましたが、大丈夫ですか？
記事は毎週継続的に更新されており 、WeChatで「 SanTaizi Ao Bing 」を検索して 、できるだけ早く読んで更新することができます（公式アカウントはブログより1〜2早いです）。この記事 は GitHubhttps ：//github.com/JavaFamilyに 含まれています。一次大手工場の面接サイトのマインドマップも、私のドキュメントをたくさん整理してくれました。スターへようこそ。それらを改善してください。面接のレビューのためにテストサイトを参照できます。私たちが一緒に何かを持てることを願っています。