Redis は現在、次の 5 つのデータ型をサポートしています。
- 文字列（文字列）
- リスト（リスト）
- ハッシュ (辞書)
- セット（コレクション）
- ソートセット (順序付けられたコレクション)
Redisのデータ構造はインターネットで色々調べてみましたが、個人的には集合や交差、差分などを使う方が便利な気がします。たとえば、チャネル データとローカル注文はアカウント調整のために 2 つの別個のコレクションに入れられ、ローカル欠落注文とチャネル欠落注文をすぐに区別することができます。
Redis の永続性
デフォルトの永続スナップショットのスナップショット
コマンドの実行時に別の追加専用ファイル (追加専用ファイル) AOF が実行され、実行されたコマンドがハードディスクにコピーされます。
スナップショット構成
スナップショットの撮影
スナップショットはデフォルトの永続化方法です。メモリ上のデータをスナップショットとしてバイナリファイルに書き込む方法で、デフォルトのファイル名はdump.rdbです。構成設定を通じて、スナップショットを自動的に保持する方法を構成できます。m 個を超えるキーが n 秒以内に変更された場合に自動的にスナップショットを作成するように Redis を構成できます。デフォルトのスナップショット保存構成は次のとおりです。
save 900 1 #900 秒以内に複数のキーが変更された場合、スナップショットの保存を開始します
save 300 10 # 300 秒以内に 10 個を超えるキーが変更された場合、スナップショットの保存が開始されます
60 10000を節約
以下に、スナップショット保存プロセスの詳細を説明します。
1. Redis が fork を呼び出し、子プロセスと親プロセスが存在します。
2. 親プロセスはクライアント要求の処理を継続し、子プロセスはメモリの内容を一時ファイルに書き込む役割を果たします。OS のコピーオンライトメカニズムにより、親プロセスと子プロセスは同じ物理ページを共有します。親プロセスが書き込みリクエストを処理するとき、OS は書き込む代わりに、親プロセスによって変更されるページのコピーを作成します。共有ページ。したがって、子プロセスのアドレス空間内のデータは、フォークの時点でのデータベース全体のスナップショットになります。
3. 子プロセスが一時ファイルへのスナップショットの書き込みを完了した後、元のスナップショット ファイルを一時ファイルに置き換えて、子プロセスが終了します。
クライアントは、save または bgsave コマンドを使用して、スナップショットの永続化を Redis に通知することもできます。保存操作はメイン スレッドにスナップショットを保存します。redis はメイン スレッドを使用してすべてのクライアント リクエストを処理するため、このメソッドはすべてのクライアント リクエストをブロックします。したがって、使用はお勧めできません。もう 1 つの注意点は、スナップショットが永続化されるたびに、メモリ データがディスクに一度完全に書き込まれ、ダーティ データのみが増分同期されないことです。データの量が大きく、書き込み操作が多い場合、必然的に大量のディスク IO 操作が発生し、パフォーマンスに重大な影響を与える可能性があります。
また、スナップショット方式は一定間隔で一度実行されるため、redis が予期せずダウンした場合、最後のスナップショット以降の変更はすべて失われます。
stop-writes-on-bgsave-error はい スナップショットの作成が失敗した後、書き込みコマンドの実行を継続するかどうか
rdbcompression がスナップショット ファイルを圧縮するかどうか
Redis プロセスがプロセスの子プロセスを作成するには、メモリが 1 GB 占有されるごとに 10 ～ 20 ミリ秒かかります。20G メモリの Redis BGSAVE には 4 ～ 6 秒かかります。
子プロセスの作成による Redis の停止を防ぐために、自動保存をオフにし、BGSAVE または SAVE を手動でトリガーすることを検討できます (SAVE コマンド Redis サーバーは、スナップショットが作成されるまで他のコマンドに応答しません)。
AOF
Aof はスナップショット メソッドよりも優れた永続性を持っています。これは、aof 永続メソッドを使用すると、redis が書き込み関数 (デフォルトは appendonly.aof) を通じて受信した各書き込みコマンドをファイルに追加するためです。Redis が再起動すると、ファイルに保存された書き込みコマンドを再実行することにより、データベース全体の内容がメモリ内に再構築されます。もちろん、OS はカーネルへの書き込みによって行われた変更をキャッシュするため、すぐにはディスクに書き込まれない可能性があります。このように、aof メソッドの永続化により、一部の変更が失われる可能性があります。ただし、fsync 関数を通じて OS にディスクへの書き込みを強制したい場合は、構成ファイルを通じて Redis に指示できます。以下の 3 つの方法があります (デフォルト: fsync 1 秒に 1 回)
appendonly yes //aof 永続モードを有効にする
# appendfsync always //書き込みコマンドを受信するたびに強制的にディスクに書き込みます。最も遅くなりますが、完全な永続性が保証されるため、推奨されません
appendfsync eachsec // 1 秒に 1 回ディスクに強制的に書き込みます。パフォーマンスと永続性の適切な妥協点として推奨されます。
# appendfsync no //OSに完全依存、パフォーマンスは最高、永続性は保証されない
aof の方法には別の問題も伴います。永続ファイルはますます大きくなります。たとえば、incr test コマンドを 100 回呼び出した場合、100 個のコマンドすべてをファイルに保存する必要がありますが、そのうち 99 個は冗長です。データベースの状態を復元するには、セット テスト 100 をファイルに保存するだけで十分であるためです。aofの永続ファイルを圧縮するため。Redis は bgrewriteaof コマンドを提供します。このコマンドを受信すると、redis はスナップショットと同様の方法を使用してメモリ内のデータをコマンドとして一時ファイルに保存し、最終的に元のファイルを置き換えます。具体的なプロセスは次のとおりです
1. Redis がフォークを呼び出し、父と子の 2 つのプロセスが存在します
2. 子プロセスは、メモリ内のデータベース スナップショットに従って、データベースの状態を再構築するコマンドを一時ファイルに書き込みます。
3. 親プロセスは、元の aof ファイルへの書き込みコマンドの書き込みを除いて、クライアント要求の処理を続行します。同時に、受信したライトコマンドをキャッシュします。これにより、子プロセスが書き換えに失敗しても問題は発生しません。
4. 子プロセスがコマンド モードでスナップショットの内容を一時ファイルに書き込んだ後、子プロセスは親プロセスに通知するシグナルを送信します。次に、親プロセスも、キャッシュされた書き込みコマンドを一時ファイルに書き込みます。
5. これで、親プロセスは古い aof ファイルを一時ファイルに置き換えて名前を変更できるようになり、後で受信した書き込みコマンドも新しい aof ファイルへの追加を開始します。
aofファイルの書き換え操作は、古いaofファイルを読み取るのではなく、コマンドによってメモリ全体のデータベースの内容を新しいaofファイルに書き換える操作であり、スナップショットに似ています。
記事画像迎撃Redis実戦