あなたは基本的なコマンドのRedisのと基本的な使い方がわからない場合は、参照
[コレクション]のRedisのRedisのは、基本的なコマンドを学習
キャッシュ
もう一つの重要な応用分野は、Redisのある - キャッシュ
図の参照は、アーキテクチャ内のユーザの位置からキャッシュを説明します
デフォルトでは、次の図の当社のサービスアーキテクチャは、クライアントがサービスを要求し、その後、mysqlデータベースサービスを読みに行きます
問題は十分ではありません、データベースが最も重要な側面の全体構造であり、それは高い同時実行され、データベースのパフォーマンスに存在し、高い書き込み頻度の時間が非常に簡単に彼らが、これは意思決定のデータベース自体の一般的な特性である、アウト崩壊します建築のパターンは、並行性のより多くの量を負担する運命ではないので、キャッシュがあります：
MySQLからの問い合わせに行くされていない場合、データがキャッシュに存在する場合、対話をサービスと高速キャッシュは直接、クライアントに返されます。データベースへの圧力を軽減、ダウンタイムを回避し、効率を向上させます。
このような上記のセクションとして、数万の瞬間まで流れることが売られ過ぎの問題は、我々は、データベースへのこれらの要求に応えることができないので、遅い言いませんが、ダウンタイムにも受けます。
キャッシュを述べ、あなたはキャッシュが問題に直面しなければならないほとんどとして、以下の4話のキャッシュ名シーンを言わなければなりません。
キャッシュの内訳
xxは今、ビジネスのロビーでシナリオを想像してみて
ジョン・ドウ、王呉、趙六、マネー、劉8人が陳九〇から七キューイングされています
窓を持っているOfficeは、いくつかの自動サービス機があり、ウィンドウ内の同志は突然人だけを受けたが、同じ速自動サービス機は、多くの人々をすぐに受け取ることができます。
さて、突然、自動サービス機は悪いです... Mangsiウィンドウの下同志が直接終了働くことを拒否内のすべて並んで窓、！
この例では、キャッシングなどの自動サービス機は、セールスマンデータベース、遅いより自動機械処理能力、そして非常に簡単揚げ髪のように、バッファの役割を果たしました。
キャッシュの内訳は、ときにキャッシュの失敗、または突然無効なキャッシュのピーク時に、それはすべての要求が降伏キャッシュを引き起こし、ラインアップするために、データベースに行く起こすようなものです。
キャッシュ・データベースは、この場所の特殊なマルチ敵は、それが故障のキャッシュの原因となりますので、もし、何のエネルギーが存在しない場合、敵がどこかで来た保護エネルギーシールドの追加に相当します。私たちが必要とするキャッシュデータからのクエリは、データベースを照会するつもりはないとき。ハッカー、またはピークトラフィックによって、キャッシュ内のデータに頻繁にアクセスがない場合、キャッシュは存在意義を失うことになる、すべての要求のための圧力モーメントがデータベースに落ち、これはデータベース接続の例外が発生します。
ソリューション：
-
定期的なバックグラウンドタスク、キャッシュデータを更新するためのイニシアチブを設定します。このプログラムは、理解しやすい自動サービス機プラスメンテナンススタッフの横にある、悪いとすぐに修理が、マシンははるかに複雑、保守担当者は、操作がまだあるときにキーが散在セットを行うことができませんより複雑な
-
階層キャッシング。それは何を意味する、つまり、時間によって、第二段階ですぐに最初に、通常は最初に、2つのキャッシュ保護層の第1セットを、修理の第二段階を2台のビジネス・マシンを壊し入れ、レベル1キャッシュの無効化時間が短い、長いレベル2キャッシュの有効期限です。見つけるための優先順位レベル1キャッシュからの要求は、レベル1キャッシュで見つかった該当データ、スレッド、スレッドをロックし、データベースはレベル1とレベル2キャッシュに更新されてから、データを取ることがない場合には、があります。他のスレッドは、レベル2のスレッドから直接入手可能です
キャッシュの浸透
多数のリクエストとしてキャッシュが直面している基本的にキャッシュ浸透し、故障の問題は、データベースを落ちます。
しかし、出発点は、多数の要求で、その結果、わずかキャッシュ貫通質問に、高い同時実行の下で、クエリ値が存在しない場合、キャッシュがヒットすることはありませんではないアクティビティがシステムクエリに存在しないなど、データベース内に直接落ちます活動。
データがキャッシュされているときに、他の言葉で、内訳は存在するが、キャッシュされていない、とキャッシュ浸透値が存在しないへのアクセスです。シナリオを想像して、ハッカーは、データ・インタフェースは、活動期限が切れてい傍受し、それを求めるために続けて、イベント自体の有効期限が切れているので、それが可能である今回は、キャッシュがヒットしないだろう、データベースに対するすべての要求に上陸し、この時間キャッシュ浸透を引き起こして。
キャッシュの浸透、問題の多くのソリューションがあります
直接キャッシュNULL値
これは理解しやすいですが、私は、データキャッシュを持っていなかった場合でも、あなたは次の空のデータの上にヒットします。
このメソッドは、キャッシュの値が長すぎるために空にすることはできませんよう、特別な注意が必要で、実際にデータを持っている場合、それ以外の場合は、通常の業務の流れに影響を与える可能性があります。
ブルームフィルタ
ブルームフィルタとは何ですか
ブルームフィルタは、値が存在しない判断し、その後、100％の値が存在しません
ブルームフィルタは、値の存在、90％の存在の値を決定します
ブルームフィルタは、本質的にビットのアレイ、1ビットのみを占めるアレイの各ビットアレイ素子です。各要素は、0又は1であることができます。このような万ビットアレイ素子の応用は、空間の8分の10000 = 1250 Bを占めます。ビット数に加えて、ブルームフィルタ基、及びKのハッシュ関数。
ちょっと待って、それは少しの周りではない、私は本当に理解していません。
私たちは（あなたが知らない？HashMapのそれの実装を見て）それは、あなたが長さとモジュロインデックス値を取得することができ、対応するデジタル値に基づいてハッシュ関数を生成することができます知っています
それとも、それは問題ではない、それは最初に次のことを理解することができ、ハッシュを達成する方法がわからない、我々は値に基づいてインデックスを取得するために、この関数はint型getIndex（String値）を想定している置きます
我々は、配列の長さが5であるとし、各要素の値は0であります
0、0、0、0、0
今、私たちは5つのデータベースIDの合計であります
A、B、C、D、E
今、私たちは、getIndex機能IDを取得することができます実行します
getIndex（A）= 0
getIndex（B）= 1
getIndex（C）= 1 //いくつかの誤差関数を仮定
getIndex（D）= 2
getIndex（E）= 3
今は存在しないIDに存在するかを決定する方法F新しい要素は、来る、と思いますか？
getIndexアレイと関連付けられている私たちは、添字getindexの値として、開始値1を設定し、配列になります
1、1、1、1、0
我々は再び仮定すると、getIndex（F）= 4、Fがあるか否かを判定する
[OK]を、私たちはよく存在しない0、1があり、配列の添字4が1であるかどうかを判断する必要があります
何getIndex（F）= 2、それならば？私たちは、神の視点を持っていた、Fが存在しないことは明らかであるはい。
ブルームフィルタは、100％の配列要素が実際に存在するか否かを判断するが、このアルゴリズムは、100％の程度を決定することができ、それは、ハッシュ関数に応じて、アレイに存在しません
ブルームフィルタは、キャッシュの侵入を防ぎます
ブルームフィルタを理解することによって、私たちは、ほとんど無効な要求をフィルタリングすることができ、すべてのIDのデータベースには、直接がない場合、要求は判決を来たときに、ブルームフィルタに一度解決getindexですライン上で空を返します
キャッシュの雪崩
キャッシュは時間をかけて集中している場合は、期限が切れていたキャッシュの浸透の多くが発生し、すべてのクエリは、キャッシュ雪崩で、その結果、データベース上に落ちます。
実際には、理論とキャッシュ内訳は、同様の致命的な障害は、故障データベースを引き起こしています。
アバランシェ降伏は、雪崩の故障の濃度は言葉を強調していることで異なっています
想像して - 私は今、3つのキャッシュキーがRedisの存在する一日の有効期限を持っています
翌日、それが今回のキー故障の焦点は、また故障を引き起こす可能性があるので、私のキャッシュ破壊の問題が、解決されている場合でも、3つの主要の同時故障が生じ、同時にキーキャッシュの設定ためかもしれません！これは、順序がちょうどxとyの間の関係として、xはキーのどれだけを示し、yはどのように多くのリクエストを示し、変更されています。。。
ソリューション
- 別の有効期限時間を設定します
熱データ
あなたは、各キャッシュにヒットしたことがないことができます。良いキャッシュ戦略とは何か、良いキャッシュ戦略は、ホットデータを識別できるようにすることです、そしてホットスポットは、良好なキャッシング戦略に必要な条件の一つであるヒットを確保するために読み取ることがとき。
キャッシュ・コヒーレンシ
データおよびキャッシュデータベースのデータは、一貫性のカテゴリに、一貫した不可能コヒーレントと強い最終データです。
キャッシュを使用しないように強力な合意
キャッシュはのみ行うこと最終データの整合性を確保することができます。
我々は可能な限りのデータの一貫性を確保されて行うことができます。
ライブラリを削除してキャッシュを削除したり、キャッシュを削除してからデータベースを削除するかどうかを、すべてのデータの不整合が、我々は彼らの順序を保証することはできません、なぜなら、同時読み取りおよび書き込み操作の発生する可能性があります。
特定のビジネスニーズを開発するための戦略。
そして、キャッシュから期限切れになります
Redisの有効期限は設定してください。キーがある場合はどのように期限切れの削除するには？
Redisのは時間指定されていない各キーが削除監視する定期的なタスクであるために、それは不可能である、それはサーバリソースを使い果たしますノートを削除し、定期的に削除するために使用されます。
デフォルトは100ミリ秒ごとに検出されたシーケンスの検出を削除する期限切れの鍵はここではない遭遇したが、ランダムテスト一回テストされています。
さらに、ネットを通じてスリップを防止するために、例えば、ギャップ100ミリ秒のチェックの途中で、キーの有効期限が切れますが、同じアクセスキーにして読むとき、トリガー不活性削除ポリシーは、その後期限切れの削除、Redisのはすでに期限切れかどうかを判断しますと、入力されました。
Redisのキーのうち、メモリの一部を指し、自動的にメモリの場合には削除されます十分ではありませんので、場合は、キャッシュからのデータが表示されます見つけることができません。
例えば、2Gのが、ビジネスデータキャッシュの開発に当社のサーバーメモリが2Gを超えました。しかし、これは我々のプログラムの動作には影響を与えません。だから、Redisのは確保されます特定の低熱データは、新しいキーを格納するためのスペースを解放、主要戦略のリストから除外しました
...継続的に更新