Redisのデータ構造の簡単な説明
Redisには5つの一般的なデータ構造、3つの特別なデータ構造（ここでは説明しません）の
一般的に使用されるデータ構造 があります：
STRING：
整数値とSDS（単純な動的文字列）によって実装されるオブジェクトです。
アプリケーションのシナリオ：
1キャッシュとして使用できます
。2.カウンターとして使用できます。3 .
共有ユーザーセッションとして使用できます。
HASH：これは、圧縮リストと辞書によって実装されたハッシュオブジェクト
アプリケーションシナリオです：
1.ユーザー関連情報を格納するためのリレーショナルデータベースストレージとして使用できます
LIST：圧縮リストと両端リンクリストによって実装されたリストオブジェクト
アプリケーションですシナリオ：
1.左から右へのコマンドを使用して、ブロックキューを実現するメッセージキューとして使用できます
。2.ブログのユーザーの記事リストなどのデータページングとして使用できます。
SET：整数のコレクションと辞書によって実現されるコレクションオブジェクト
アプリケーションシナリオです
。1.ラベル
2.共通の友達
3.独立したIP
ZSET：圧縮リスト、辞書、ジャンプテーブルによって実装されたオブジェクトの順序付けられたセットです。
アプリケーションシナリオ：
1.特定のフィールドに従ってソートできるランキング
2.ウェイトを計算し、ウェイト値を設定し、ウェイトルールに従ってスレッドを実行します
Redisの永続化メカニズムであるRDBとAOFについて簡単に説明します
どちらもredisの永続化メカニズムです
RDBはスナップショットレベルの永続性であり、saveコマンドとbgsaveコマンドを介してバイナリストリームファイルの形式で永続化されます。saveコマンドを実行すると、Redisサーバープロセスはブロックされます。RDBファイルが生成されるまで、Redisサーバーは他のコマンドを実行して操作を要求することはできません。bgsaveコマンドを実行すると、Redisサーバーは子プロセスをフォークしてRDBファイルの生成を実行します。 、これはバックグラウンドでの実行と同じです。現時点では、Redisサーバーは非ブロッキング状態です。他のコマンドによって要求された操作を実行できます。Redisでは、メインプロセスと子プロセスが同時にsaveコマンドまたはbgsaveコマンドを実行することを許可しないことに注意してください。プロセスと子プロセスには競争関係があります。
AOFはログレベルの永続性です。データベースを操作するためのコマンドをaofファイルの最後に追加します。ダウンタイムがある場合、aofファイル内のコマンドが再度読み込まれて実行され、データベースの状態を回復する目的を達成します。間隔の保存方法には2種類あり、1つはコマンド操作で1回書き込む方法、2つ目は1秒ごとに書き込む方法、3つ目は書き込み間隔処理をシステム管理に転送する方法です。AOFのデフォルトでは、 1秒に1回書き込みます。
Redisの設定ファイルではRDBがデフォルトでオンになっており、AOFはデフォルトでオフになっていますRedisの設定ファイルでデフォルトのsaveコマンドを実行するには、3つの方法があります。
save 900 1 --------------- 900Sでは、データベースは少なくとも1回は変更されています
save 300 10 -------------- 300Sでは、正しいデータベースが少なくとも10回変更されて
60が保存された10000 ------------ 60S以内に、データベースが少なくとも10,000回変更された
Redisの高い同時実行で発生する可能性があるビジネスシナリオの内訳、侵入、雪崩、およびソリューション
壊す：
ホットキー（Weiboでのホット検索など）の1秒あたりのリクエスト数が10,000の場合、アクセスは非常に頻繁に行われ、同時実行性が高い状態になります。このキーの有効性が突然無効になった場合、現時点では1秒あたり10,000回リクエストはデータベースに直接ヒットしますが、データベースはこのような高頻度のアクセスに耐えられないため、データベースが強制終了されます。
解決する：
ホットスポットデータが期限切れにならないように設定するか、相互排他ロックを実装します。ロック->キャッシュマシンが初めてアクセスしたデータをキャッシュするのを待ちます->ロックを解除して、同じデータへの後続の同時並行アクセスが直接行われるようにします。データはキャッシュから取得されて返されます。
貫通：
1秒あたり10,000リクエストがあり、そのうち8,000リクエストが攻撃者によって送信されたと仮定すると、そのようなIDはキャッシュとデータベースで見つかりません（このIDは負の数であると想定できます）。この場合もデータベースを強制終了します
解決する：
キャッシュまたはデータベースで最初に見つからないキーである限り、対応する値をnullに設定してキャッシュに書き込みます。これにより、後で7999のリクエストがあったとしても、毎回ではなく直接nullを返すことができます。データベースで検索する必要があります
雪崩：
1秒あたり10,000リクエストがあり、キャッシュマシンが1秒あたり最大8,000リクエストを処理できる場合、明らかに問題はありませんが、キャッシュマシンが突然ダウンした場合、これらの8,000リクエストが直接追加されます。データベース上では、データベースは必然的にそれをサポートできなくなります。理論的には、最初に警察に電話してから電話を切りますが、実際には、直接電話を切る可能性が高くなります。
解決する：
事前：Redisは高可用性、読み取り/書き込み分離、マスター/スレーブレプリケーション+センチネルモード、redisクラスターで、完全なクラッシュを回避します。
イベントの場合：ローカルのehcacheキャッシュ+ hystrixの現在の制限とMySQLの強制終了を防ぐためのダウングレード。
イベント後：Redisは持続します。再起動すると、データはディスクから自動的にロードされ、キャッシュされたデータをすばやく復元します
Redisトランザクション
オープントランザクション
マルチ
実行コマンド
exec in コマンドキュー
クローズトランザクション
破棄
監視ロック監視キー
キャンセル監視監視解除