キャッシュを使用する理由
（1）パフォーマンス下図に示すように、長時間実行する必要のあるSQLに遭遇し、結果が頻繁に変更されない場合（ビジネスの基本データや休日のデータなど）、特に適しています。実行結果をキャッシュに入れます。このようにして、後続のリクエストがキャッシュから読み取られるため、リクエストに迅速に応答できます。
余談：私は突然、この迅速な対応の基準について話したいと思いました。実際、相互作用の影響によっては、この応答時間の固定基準はありません。しかし、ある記事を見たことがあります。「夏の理想的な状態では、ページジャンプを瞬時に解決する必要があり、ページ内の操作では瞬時に解決する必要があります。また、時間のかかる操作も必要です。指先を超える場合は、進行状況のプロンプトが表示される必要があります。また、ユーザーに最高のエクスペリエンスを提供するために、いつでも一時停止またはキャンセルできます。」
では、インスタント、インスタント、またはフラッシュにどのくらいの時間がかかりますか？
「マハサンガの法則」の記録によると
瞬間は思考であり、20の思考は瞬間であり、20の瞬間はフリックであり、20のフリックは予感であり、20の予感は瞬間であり、昼と夜に30の瞬間があります。
そして、慎重に計算すると、0.36秒で一瞬、0.018秒で一瞬、7.2秒で指をフリックします。
（2）同時実行性次の図に示すように、同時実行性が大きい場合、すべての要求がデータベースに直接アクセスし、データベースには接続例外が発生します。現時点では、Redisを使用してバッファリング操作を実行し、リクエストがデータベースに直接アクセスするのではなく、最初にRedisにアクセスするようにする必要があります。
優れたキャッシングシステムRedis
Redisは完全にオープンソースで無料です。C言語で記述されており、BSDプロトコルに準拠しています。高性能の分散メモリデータベースです。メモリ上で実行され、永続性をサポートするNoSQLデータベースです。現在、最も人気のあるNoSQLデータベース。人々はデータ構造サーバーと呼ばれます。
他の同様の製品と比較して、Redisには次の利点があります。
- Redisはデータの永続性をサポートしています。これにより、データをディスク上のメモリに保持し、再起動時に使用できるように再度ロードできます。
- Redisは、単純なKey-Valueタイプのデータをサポートするだけでなく、リスト、セット、zset、ハッシュ、およびその他のデータ構造のストレージも提供します
- Redisはデータバックアップ、つまりマスタースレーブモードでのデータバックアップをサポートしています
なぜredisはとても速いのですか
主に以下の3点
- 純粋なメモリ操作
- シングルスレッド操作により、頻繁なコンテキスト切り替えが回避されます
- ノンブロッキングI / O多重化メカニズムを採用
余談：このステートメントは非常に人気があり、ほとんどの人がそれが何を意味するのか理解できないため、I / O多重化メカニズムについて慎重に説明する必要があります。ブロガーはアナロジーを使用します。Xiaoquは深センに宅配便店をオープンし、同じ都市で速達サービスを担当しました。財政的制約のため、Xiaoquは宅配便業者のグループを雇いましたが、Xiaoquは資金が十分ではなく、宅配便を配達するために車を購入するのに十分であることに気付きました。
ビジネス方法1顧客が死にかけているコピーを送るたびに、Xiaoquは宅配便業者にそれを見つめるように頼み、次に宅配便業者は宅配便を配達するために運転します。ゆっくりと、このビジネス方法で次の問題を発見しました
- 何十人もの宅配便業者が基本的に車を奪うことに時間を費やしています。ほとんどの宅配便業者はアイドル状態です。車を奪う人は誰でも急行を配達できます。
- 速達の増加に伴い、宅配便業者が増えています。Xiaoquは、エクスプレスストアがますます混雑しており、新しい宅配便業者を雇う方法がないことに気づきました。
- 宅配便の調整には時間がかかります
上記の欠点に基づいて、Xiaoquはそれから学び、次のビジネスモデルを提案しました。これ
は、2番目の操作モードであり、 Xiaoquは1つの宅配便のみを採用します。次に、お客様から送られてきた宅配便で、小さな曲に配達場所の番号が記され、1か所に順番に配置されます。最後に、宅配便業者は、宅配便業者を1つずつ受け取りに行き、車を運転して宅配便を配達し、配達されたら戻ってきて宅配便を受け取りました。上記の2つのビジネス方法を
比較すると、 2番目の方法の方が効率的で優れていることは明らかですか？上記の例えでは：
- 各宅配便——————>各スレッド
- 各エクスプレス————>各ソケット（I / Oストリーム）
- 宅配便の配達場所——————>ソケットのステータスが異なる
- 顧客がエクスプレスリクエストを送信——————>クライアントリクエスト
- Xiaoquのビジネスモード——————>サーバーで実行されているコード
- 車——————> CPUコアの数、
つまり次の結論が得られます。1。最初の操作モードは従来の同時実行モデルであり、各I / Oストリーム（エクスプレス）には新しいスレッド（宅配便）があります。 ）管理。2. 2番目の動作モードは、I / O多重化です。各I / Oストリームのステータス（各宅配便の配達場所）を追跡することにより、単一のスレッド（宅配便）のみが複数のI / Oストリームを管理します。
図に示すように、実際のredisスレッドモデルに次のように類似しています。
上の図を参照すると、簡単に言えば、redisクライアントは動作時にさまざまなイベントタイプのソケットを生成します。サーバー側には、キューに配置されるI / O多重化プログラムがあります。次に、ファイルイベントディスパッチャは順番にキューに移動し、それらを別のイベントハンドラに転送します。このI / O多重化メカニズムのために、redisはselect、epoll、evport、kqueueなどの多重化関数ライブラリも提供することに注意してください。これについては自分で学ぶことができます。
redisのデータ型と各データ型の使用シナリオ
（1）文字列は
実際には何も言うことはありません。ほとんどの従来のset / get操作では、値は文字列または数値のいずれかです。一般に、いくつかの複雑なカウント関数のキャッシュを実行します。
（2）
ここでのハッシュの値は構造化オブジェクトであり、フィールドの1つを操作する方が便利です。ブロガーがシングルサインオンを行う場合、ブロガーはこのデータ構造を使用してユーザー情報を格納し、cookieIdをキーとして使用し、キャッシュの有効期限イベントとして30分を設定します。これにより、同様の効果をシミュレートできます。
（3）List
は、単純なメッセージキュー関数として使用できるListのデータ構造を使用します。もう1つは、lrangeコマンドを使用して、優れたパフォーマンスと優れたユーザーエクスペリエンスを備えたredisベースのページング機能を実行できることです。
（4）セット
が積み上げられているので、繰り返しのない組み合わせに値するセットです。したがって、グローバルな重複排除機能を実行できます。重複排除にJVM組み込みセットを使用してみませんか？私たちのシステムは一般的にクラスターにデプロイされているため、JVMに付属のセットを使用するのは面倒です。グローバルな重複排除を実行してパブリックサービスを開始するのは面倒ですか？さらに、共通部分、和集合、減算などの演算を使用して、共通の設定、すべての設定、および独自の特別な設定を計算できます。
（5）ソートさ
れたセットソートされたセットには追加の重みパラメータースコアがあり、セット内の要素はスコアに従って配置できます。これは、ランキングアプリケーションとして使用でき、TOPN操作を実行できます。さらに、別の「分散遅延タスクスキームの分析」を参照して、ソートされたセットを遅延タスクに使用できることを指摘しました。最後のアプリケーションは、範囲検索を実行することです。
Redisの有効期限戦略とメモリ除去メカニズム
分析：この問題は実際にはボックスリストにとって重要です。結局のところ、redisが使用されているかどうかに関係なく、この問題が見られます。たとえば、redisは5Gデータしか保存できませんが、10Gを書き込むと、5Gデータは削除されます。削除する方法、この質問について考えましたか？また、データの有効期限が切れたイベントが発生しましたが、時間切れであり、メモリ使用量はまだ比較的高いです。理由について考えましたか？回答：Redisは通常の削除+遅延削除戦略を使用します。ポリシーを定期的に削除してみませんか？タイムリーに削除し、タイマーを使用してキーの監視を担当し、有効期限が切れると自動的に削除します。メモリは時間内に解放されますが、CPUリソースを非常に消費します。大規模な同時リクエストでは、CPUはキーを削除する代わりに時間を使用してリクエストを処理するため、この戦略は採用されていません。定期的に+怠惰に削除する場合、どのように機能しますか？定期的に削除します。redisはデフォルトで100ミリ秒ごとに期限切れのキーがあるかどうかを確認し、期限切れのキーがある場合はそれを削除します。redisは100msごとにすべてのキーをチェックするのではなく、検査のためにランダムに選択することに注意してください（100msごとにすべてのキーがチェックされる場合、redisはスタックしません）。したがって、通常の削除戦略のみを採用した場合、その時点で多くのキーが削除されることはありません。したがって、遅延削除は便利です。つまり、キーを取得すると、redisは以下をチェックします。キーに有効期限が設定されている場合、有効期限はありますか？有効期限が切れた場合、この時点で削除されます。**定期的な削除+怠惰な削除に他の問題はありませんか？**いいえ、定期的にキーを削除すると、キーは削除されません。次に、時間内にキーを要求しませんでした。これは、遅延削除が有効にならなかったことを意味します。このようにして、redisのメモリはどんどん高くなります。次に、メモリ除去メカニズムを使用する必要があります。redis.confに構成行があります
# maxmemory-policy volatile-lru
この構成には、メモリ除去戦略が装備されています（何を構成していませんか？自分でよく見てください）
メモリが新しく書き込まれたデータを収容するのに十分でない場合は、次のパラメータ構成を使用します
1）noeviction：new write操作はエラーを報告します。
2）allkeys-lru：キースペースで、最も使用頻度の低いキーを削除します。推奨。
3）allkeys-random：キースペースのキーをランダムに削除します。
4）volatile-lru：有効期限が設定されたキースペースにいる場合は、最も使用頻度の低いキーを削除します。この状況は通常、redisがキャッシュおよび永続ストレージとして使用される場合に使用されます。
5）揮発性ランダム：有効期限が設定されたキースペースで、キーがランダムに削除されます。
6）Volatile-ttl：有効期限が設定されているキースペースでは、有効期限が早いキーが最初に削除されます。
ps：有効期限キーが設定されていない場合、前提条件が満たされていません。その場合、volatile-lrn、volatile-random、およびvolatile-ttl戦略の動作は、基本的にnoevicationと同じです（削除されません）。
プログレッシブリハッシュ
プログレッシブリ
ハッシュの理由リハッシュプロセス全体は、1つのステップではなく、複数の段階的なステップで完了します。膨大な数のキーと値のペアがハッシュテーブルに格納されている場合、再ハッシュを1回実行すると、サーバーがクラッシュする可能性があります。
プログレッシブリハッシュステップ
- ディクショナリが2つのハッシュテーブルht [0]とht [1]を同時に保持するように、ht [1]にスペースを割り当てます。
- インデックスカウンター変数rehashidxを維持し、その値を0に設定して、再ハッシュが開始されることを示します。
- ディクショナリが追加、削除、変更、およびチェックされるたびに、ht [0]からht [1]のrehashidxインデックスのすべてのキーと値のペアを再ハッシュし、rehashidxの値を+1に追加します。
- ht [0]のすべてのキーと値のペアがht [1]に再ハッシュされると、プログラムはrehashidxの値を-1に設定し、再ハッシュ操作が完了したことを示します。
注：プログレッシブリハッシュの利点は、を採用することです。分割統治法。再ハッシュのキーと値のペアの計算は、辞書の追加、削除、変更、およびクエリ操作ごとに均等に分散されるため、複数のタイプの再ハッシュの大量の計算を回避できます。
キャッシュの浸透
概念：存在しないキーにアクセスすると、キャッシュは機能せず、要求はDBに浸透し、トラフィックが大きい場合はDBがハングします。
解決策：
- ブルームフィルターを使用し、アクセスされる可能性のあるキーを格納するのに十分な大きさのビットマップを使用し、存在しないキーを直接フィルターで除外します。
- アクセスキーはDB内で値を検出せず、空の値もキャッシュに書き込まれますが、より短い有効期限を設定できます。
キャッシュアバランシェ
概念：同じ有効期限で多数のキーが設定されると、すべてのキャッシュが同時に無効になり、大量の瞬間的なDB要求と突然の圧力の増加が発生し、雪崩の
解決策が発生します。
- キャッシュの有効期限を設定するときにランダムなイベントを追加して、各キーの有効期限が分散され、同時に複数の無効化が発生しないようにすることができます。
- 電流制限アルゴリズムを使用してフローを制限します。
- 分散ロックとロックアクセスを使用します。
キャッシュの内訳
概念：通常の同時実行性の高いシステムでは、多数のリクエストが同時にキーをクエリすると、この時点でキーが失敗するだけで、データベースに多数のリクエストがヒットします。ある瞬間にデータベース要求が多すぎて、プレッシャーが急激に高まります。
スキーム：
- 分散ロックでは、キャッシュを取得できず、ロック制御を介してデータベースを再読み取りできない場合、残りのスレッドは、ロックが解放された後にキャッシュを直接再読み取りします。
- キーの有効期限戦略を調整し、事前にホットキーをキャッシュし、システムの起動後にチェックスレッドを開始します。ホットキーの有効期限が近づいたら、データベースデータをキャッシュに再読み込みして、直接侵入しないようにします。
- ホットスポットデータが期限切れにならないように設定する