この記事では、redis の 2 つの永続化メカニズム (RDB と AOP) について説明します。皆様のお役に立てれば幸いです。
#Redis はインメモリ データベースであり、データはメモリに保存されますが、メモリ内のデータは急速に変化し、問題が発生しやすいことは誰もが知っています。損失。幸いなことに、Redis は、RDB (Redis DataBase) と AOF (Append Only File) という永続化メカニズムも提供します。 [関連する推奨事項: Redis ビデオ チュートリアル ]
ここでは、redis の基本的な構文をすでに理解していることを前提としています。ある alphabet の Web サイトに優れたチュートリアルがあるので、チェックしてみてください。基本的な使い方については記事には書きませんが、どれもよく使うコマンドです。
以下では、これら 2 つの方法について説明します。浅いところから深いところまで。
Redis データはディスクに保存できるため、このプロセスはどのようなものになるでしょうか?
次の 5 つのプロセスが必要です。
(1) クライアントは書き込み操作をサーバーに送信します (データはクライアントのメモリ内にあります)。
(2) データベース サーバーは書き込み要求のデータを受信します (データはサーバーのメモリ内にあります)。
(3) サーバーは、write システム コールを呼び出して、データをディスクに書き込みます (データはシステム メモリのバッファ内にあります)。
(4) オペレーティング システムは、バッファ内のデータをディスク コントローラに転送します (データはディスク キャッシュにあります)。
(5) ディスク コントローラーは、データをディスクの物理メディアに書き込みます (データは実際にはディスク上に置かれます)。
これらの 5 つのプロセスは、理想的な条件下では通常の保存プロセスですが、多くの場合、当社のマシンなどにはさまざまな障害が発生します。データベースに障害が発生した場合でも、上記の 3 番目の手順が完了している限り、データベースを永続化して保存することができ、オペレーティング システムが残りの 2 つの手順を完了します。
(2) オペレーティング システムに障害が発生した場合は、上記の 5 つの手順をすべて完了する必要があります。
ここでは、保存プロセス中に起こり得る失敗のみを考慮します。実際には、保存されたデータも破損する可能性があり、特定の回復メカニズムが必要になりますが、ここではこれを拡張しません。ここで主に考慮すべき点は、ディスクを保存する上記の 5 つのステップを Redis がどのように実装するかです。 RDB と AOF という 2 つのポリシー メカニズムを提供します。
2. RDB の仕組みRDB 永続性とは、指定された時間間隔内にメモリ内のデータ セットのスナップショットをディスクに書き込むことを指します。これはデフォルトの永続化メソッドでもあります。このメソッドはメモリ内のデータをスナップショットの形式でバイナリ ファイルに書き込みます。デフォルトのファイル名は dump.rdb です。
redis をインストールした後、すべての設定は redis.conf ファイルに保存されます。このファイルには、RDB と AOF という 2 つの永続化メカニズムのさまざまな設定が保存されます。
RDB メカニズムはスナップショットを生成することで特定の瞬間のすべてのデータを保存するため、このプロセスを実装するトリガー メカニズムが必要です。 RDB の場合、save、bgsave、automation の 3 つのメカニズムが提供されます。個別に見てみましょう
1. トリガー メソッドの保存このコマンドは、現在の Redis サーバーをブロックします。 save コマンド、Redis は RDB プロセスが完了するまで他のコマンドを処理できません。具体的な処理は以下のとおりです。
2. bgsave トリガー メソッド#このコマンドを実行すると、Redis はバックグラウンドでスナップショット操作を非同期に実行し、スナップショットはクライアントに応答する、尋ねる。具体的なプロセスは次のとおりです:
3. 自動トリガー自動トリガーは設定ファイルによって実行されます。 redis.conf 設定ファイルには、設定できる次の設定があります。
①save: これは、Redis をトリガーする RDB 永続条件、つまりデータをいつ保存するかを設定するために使用されます。メモリをハードディスクに。たとえば、「m n を保存」などです。データセットが m 秒以内に n 回変更されると、bgsave が自動的にトリガーされることを示します。
デフォルトの構成は次のとおりです:
# は、少なくとも 1 つのキーの値が 900 秒以内に変更された場合、900 を保存することを意味します。 1# は、少なくとも 10 のキーの値が 300 秒以内に変更された場合、300 を保存することを意味します。 10# は、少なくとも 10 のキーの値が変更された場合、300 を保存することを意味します300 秒以内に 900 を保存します。10000 キーの値が変更された場合は、60 を保存します。10000
は永続化を必要としないため、すべての保存行をコメント アウトして保存機能を無効にすることができます。
②stop-writes-on-bgsave-error: デフォルト値は Yes です。 RDB が有効で、最後のデータのバックグラウンド保存が失敗した場合、Redis がデータの受信を停止するかどうか。これにより、データがディスクに正しく保存されていないことがユーザーにわかります。そうしないと、障害が発生したことに誰も気づかなくなります。 Redis が再起動されると、再びデータの受信を開始できます
③rdbcompression; デフォルト値は yes です。ディスクに保存されるスナップショットについては、保存するために圧縮するかどうかを設定できます。
④rdbchecksum: デフォルト値はyesです。スナップショットを保存した後、Redis に CRC64 アルゴリズムを使用させてデータ検証を行うこともできますが、これによりパフォーマンスの消費が約 10% 増加します。パフォーマンスを最大限に向上させたい場合は、この機能をオフにすることができます。
⑤dbfilename: スナップショットのファイル名を設定します。デフォルトは dump.rdb
⑥dir: スナップショット ファイルのストレージ パスを設定します。この構成項目はファイルではなくディレクトリである必要があります名前。
これらの構成を変更して、必要な効果を実現できます。 3 番目の方法が設定されているため、最初の 2 つを比較します:
4. RDB の長所と短所
①. 利点
(1) RDB ファイルはコンパクトで完全にバックアップされているため、バックアップや災害復旧に非常に適しています。
(2) RDB ファイルを生成するとき、redis のメイン プロセスはすべての保存作業を処理するサブプロセスを fork() します。メイン プロセスはディスク IO 操作を実行する必要はありません。
(3) 大規模なデータ セットを復元する場合、RDB は AOF よりも高速です。
② 欠点
RDB スナップショットは完全バックアップであり、メモリ データのバイナリ シリアル化形式が保存され、ストレージが非常にコンパクトになります。スナップショットの永続化が実行されると、スナップショットの永続化を特に担当する子プロセスが開始されます。子プロセスは、親プロセスのメモリ データを所有します。親プロセスによるメモリの変更は、子プロセスには反映されません。スナップショットの永続化中に変更されたデータは反映されません。保存されると、データが失われる可能性があります。
フル バックアップは常に時間がかかります。場合によっては、より効率的な AOF メソッドを提供します。動作メカニズムは非常にシンプルです。Redis はそれぞれ受信したメッセージを受け取ります。 write コマンドは、write 関数によってファイルに追加されます。一般に理解されているのはログ記録です。
1. 永続性の原則
彼の原則については、下の図をご覧ください:
書き込みコマンドが来ると、そのコマンドは AOF ファイルに直接保存されます。
2. ファイル書き換えの原理
AOF 方式には別の問題もあります。永続ファイルはますます大きくなります。 aofの永続ファイルを圧縮するため。 Redis は bgrewriteaof コマンドを提供します。メモリ上のデータをコマンド形式で一時ファイルに保存し、同時に新しいプロセスをフォークしてファイルを書き換えます。
aof ファイルの書き換え操作は、古い aof ファイルを読み取るのではなく、コマンドを使用してメモリ内のデータベースの内容全体を新しい aof ファイルに書き換えます。これはスナップショットに似ています。
3. AOF には 3 つのトリガー メカニズムもあります
(1) すべての変更後に常に同期: データが更新されるたびに同期の永続化がトリガーされます。
#(2) 1 秒ごとに同期: 非同期操作で 1 秒ごとに記録します。1 秒以内にマシンがダウンした場合、データ損失が発生します( 3) 異なるいいえ: 同期されません4. 利点
(1) AOF は次のことができます。データを損失からより適切に保護します。通常は AOF fsync 操作はバックグラウンド スレッドを通じて 1 秒ごとに実行され、最大 1 秒のデータが失われます。 (2) AOF ログ ファイルにはディスク アドレス指定のオーバーヘッドがなく、書き込みパフォーマンスが非常に高く、ファイルが破損しにくいです。 (3) AOF ログ ファイルが大きすぎる場合でも、バックグラウンドでの書き換え操作はクライアントの読み取りと書き込みに影響しません。 (4) AOF ログ ファイルのコマンドは非常に読みやすい方法で記録されるため、この機能は致命的な誤削除の緊急復旧に非常に適しています。たとえば、誰かが誤ってフラッシュオール コマンドを使用してすべてのデータをクリアしてしまった場合、その時点でバックグラウンドでの書き換えが発生していない限り、AOF ファイルをすぐにコピーし、最後のフラッシュオール コマンドを削除してから、AOF ファイルを元に戻すことができます。回復メカニズムを通じてすべてのデータを自動的に復元します5。欠点
(1) 同じデータの場合、AOF ログ ファイルは通常、RDB データ スナップショット ファイルよりも大きくなります
(2) AOF をオンにすると、サポートされる書き込み QPS は、RDB でサポートされる書き込み QPS よりも低くなります。 RDB. AOF は通常、ログ ファイルを 1 秒に 1 回 fsync するように設定されているため、もちろん、fsync は 1 秒に 1 回であり、パフォーマンスは依然として非常に高いです
(3) AOF には以前にもバグがあり、データがAOF によって記録されたログを通じて収集されましたが、リカバリ中にまったく同じデータはリカバリされませんでした。
どちらを選択する場合でも、2 つを併用したほうが優れています。 2 つの永続化メカニズムは理解できたので、残りは各自のニーズに応じて異なります。異なるニーズに基づいて必ずしも 1 つを選択できるわけではありませんが、通常は組み合わせて使用されます。要約するための図があります:
# これらの機能を比較した後、残りはあなた次第です。
プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！
以上がRedis での RDB と AOP の永続性について 1 つの記事で学びましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
