1.データ構造とオブジェクト：
Redisデータベースの各キーと値のペアはオブジェクトで構成され、キーは常に文字列オブジェクトであり、値は文字列オブジェクト（String）、リストオブジェクト（List）、ハッシュオブジェクト（Hash）、コレクションオブジェクト（セット）、順序付きセットオブジェクト（ZSet）およびその他のオブジェクト
Redisでは、ストレージの文字列型としてSDS（単純な動的文字列）を使用します。Cの文字列型と比較すると、その利点は次のように明白で目立ちます。
1.ストリングの長さを取得するための常熟の複雑さ：
文字列の長さを取得するためにC文字列のように文字列をトラバースする必要はありません。文字列の長さを取得する必要がある場合は、文字列のlen属性O（1）を読み取るだけで簡潔で便利になります。文字列の長さを取得します。取得するためにC文字列O（n）のようにすべての文字をトラバースする必要はありません。
2.バッファオーバーフローを防止します。
これは、C文字列を使用する場合のバッファオーバーフローの問題に対する適切な解決策です。文字のスプライシングが必要な場合、最初にSDSスペースがスプライスされる文字列の長さに一致するかどうかがチェックされます。それが満たされると、スプライシングは自動的に拡張されます。 SDSスペースのサイズにより、スプライスされた文字列を保持して、バッファーオーバーフローの可能性を防ぐことができます
3.文字列の変更によって引き起こされるメモリ再割り当ての数を減らします。
Redisは、スペースの事前割り当て戦略を使用して、文字列拡張の継続的な実行に必要なメモリ割り当ての数を削減します
スペースの事前割り当て戦略：
変更されたSDSの長さが1MB未満の場合、プログラムはFree = lenの事前割り当てスペースをオブジェクトに割り当てます
変更されたSDSの長さが1MBを超えると、プログラムはFree = 1MBの事前割り当てスペースをオブジェクトに割り当てます
Redisはレイジースペースリリースを使用してSDS文字列短縮操作を最適化します
不活性空間解放：
SDSによって保存された文字列を短縮する必要がある場合、プログラムはメモリの再割り当てを直接呼び出して短縮されたスペースを再利用するのではなく、Free属性を使用してこの短縮されたスペースを記録し、SDS文字列を拡大するときに将来使用できるようにします。
4.データのセキュリティを確保するためのバイナリストレージ
Redisでは、SDSキーに対応するBuf配列に格納されたデータはバイナリ形式で処理されます。プログラムはデータに対して制限、フィルタリング、または仮定を実行しませんが、データをそのまま保存します
5.一部のC文字列関数との互換性
概要：C文字列とSDSの違い：
SDSの対応する操作手順とAPIは次のとおりです。
1。
2。
2. Redis永続化メカニズムのRDBおよびAOF
1.なぜ永続化が必要なのですか？
Redisはメモリデータベースであるため、データベースの状態をメモリに保存します。永続化メカニズムを使用しない場合、プロセスが終了するとデータベースの状態は表示されなくなります。データベースの状態を適切に保持するには、データベースを保存する永続化メカニズムが必要です。データが誤って失われないように、状態はディスクに保存されます。
RDBの永続性は、データを圧縮してバイナリ圧縮ファイルを生成することです。これにより、RDBファイルが生成されたときにデータベースの状態を復元できます。
2. RDBファイルを生成する
二つの方法：
1. save ------このコマンドは、RDBファイルが生成されるまでRedisサーバープロセスをブロックします。この間、サーバーはコマンド要求を処理できません。
2. bgsave ---このコマンドはサーバープロセスをブロックしませんが、RDBファイルを生成するために子プロセスを生成します。メインプロセスは他のコマンド要求を処理し続けます
3.データの読み込み
（1）AOFファイルの更新頻度はRDBファイルの更新頻度よりもはるかに高いため、データの整合性はRDBファイルよりも比較的優れています。したがって、サーバーでAOF永続化機能が有効になっている場合、ファイルがロードされると、サーバーは優先的にAOFファイルを使用してデータベースの状態を復元します
（2）AOFが閉じている場合（デフォルト）、サーバーはRDBファイルを使用してデータベースの状態を復元します。このとき、RDBファイルのロードは、Redisサーバーの起動時に自動的にロードされます。
ノート：
RDBファイルの読み込み中、RDBファイルが完了するまで、サーバーはブロックされます
bgsaveコマンドの実行中、サーバーはsaveコマンドと別のbgsaveコマンドを拒否します。サーバーは、saveコマンドとbgsaveコマンドの同時実行を禁止します。これは、メインプロセスと子プロセスが同時に2つのrdbSave関数呼び出しを実行しないようにすることで、競合を防ぎます。
また、bgrewriteaofコマンドとbgsaveコマンドを同時に実行することはできません。場合
bgrewriteaofがされて
最初に実行され、サーバがbgsaveコマンドを拒否します。bgsaveが最初に実行された場合、サーバは実行前に実行されるようにbgsaveを待ちます
bgrewriteaof
コマンド
理由：
bgrewriteaofコマンドとbgsaveコマンドは子プロセスによって実行されます。これらが同時に実行されている場合、両方のプロセスが多くの書き込み操作を実行しています。これはパフォーマンスに影響を与えるため、明らかに良いシナリオではありません
4.自動インターバル保存
bgsaveは作業の保存にサブプロセスを使用し、サーバーのブロックを引き起こさないため、
Redisはユーザーがサーバー構成を設定して自動間隔保存の機能を実現できるようにします
Redisのデフォルト構成：
save 900 1 --------------- 900Sでは、データベースは少なくとも1回変更されています
save 300 10
-------------- 300Sでは、データベースは少なくとも10回変更されています
60 10000を保存
------------ 60Sでは、データベースは少なくとも10000回変更されました
上記の3つの条件のいずれかが満たされている限り、サーバーはbgsaveコマンドを実行してデータベースの状態を保存します
Redisは、serverCron関数を呼び出すことにより、実行中のサーバーを100ミリ秒ごとに維持します。タスクの1つは、データベースのステータスが保存条件を満たすかどうかを確認し、条件を満たす場合はbgsaveを実行することです。
3. RDBファイル構造
5文字を占めるREDISの最初の部分は、プログラムがファイルをロードするときにRDBファイルであるかどうかをすばやく検出するために使用されます
2番目の部分db_versionは4文字を占め、文字列で表される整数であり、RDBファイルのバージョン番号を記録します
3番目の部分であるデータベースは、RDBファイルの主要部分であり、0個以上のデータベースと、各データベースに格納されているキーと値のペアのデータが含まれます。
4番目の部分は、1文字を占めるEOF定数です。この定数は、RDBファイルの本文の終わりを示します。プログラムが定数を読み取ると、ロードの終わりがわかります。
5番目の部分check_sumは、8文字の符号なし整数を占め、最初の4つの部分を介してプログラムによって計算されるチェックサムを格納します。ファイルをロードすると、プログラムは最初の4つの部分に従って計算しますチェックサム。次に、計算されたチェックサムを以前にファイルに保存されたチェックサムと比較して、ロードされたファイルが破損しているか間違っているかを判断します。
ノート：
データベース部分には、1つまたは複数を含めることができます。次に例を示します。
データベース部分のデータ構造：
最初の部分であるSELECTDBは定数で、1バイトを占め、次に読み取られるのはデータベース番号になることをプログラムに通知します。
2番目の部分db_numberは、データベースの番号を格納し、1、2、および5バイトを占有して、番号のサイズに応じて決定されます。
3番目の部分key_value_pairsは、期限切れのキーと値のペアのデータを含む、対応するデータベースのすべてのキーと値のペアのデータを保存します
有効期限なしのキーと値のペアのデータ構造
：
期限切れのキーと値のペアを持つデータ構造：
最近はたくさん本を読んでいて、自分ではまとめられない気がします。タイプするときは覚えにくいです。ブログを書くことも復習や思い出に便利です。ですから、これはポストリーディングの感覚と言えます。「Redis設計と実装2」については、この段階でより簡単で理解しやすいコンテンツのみを強化の鍵として取り上げます。ジャンプテーブルの最初の部分、圧縮テーブル、辞書、両端リンクリストなどです。知識を待つ、それは少し深いかもしれませんが、とりあえず理解してください。
AOFを書いて、太った友達を一緒に励ましてください！