どの永続化戦略が Redis に適していますか?

Redis は、さまざまなレベルでさまざまな永続化メソッドを提供します:

RDB 永続化では、指定された時間間隔内でデータ セットを生成できます。 -時間のスナップショット。

AOF は、サーバーによって実行されたすべての書き込み操作コマンドを永続的に記録し、サーバーの起動時にこれらのコマンドを再実行することによってデータ セットを復元します。 AOF ファイル内のすべてのコマンドは Redis プロトコル形式で保存され、新しいコマンドがファイルの末尾に追加されます。 Redis は、AOF ファイルのサイズがデータ セットの状態を保存するために必要な実際のサイズを超えないように、バックグラウンドで AOF ファイルを書き換えることもできます。

Redis は、AOF 永続性と RDB 永続性を同時に使用することもできます。この場合、Redis が再起動すると、AOF ファイルを使用してデータセットを復元することが優先されます。これは、AOF ファイルによって保存されたデータセットは、通常、RDB ファイルによって保存されたデータセットよりも完全であるためです。

永続性をオフにして、サーバーの実行中にのみデータが存在するようにすることもできます。

RDB の知識ポイント

RDB の利点

RDB は、特定の時点で Redis データ セットを保存する非常にコンパクトなファイルです。ある時点。このタイプのファイルはバックアップ目的に最適です。たとえば、過去 24 時間について 1 時間ごとに RDB ファイルをバックアップしたり、毎月毎日 RDB ファイルをバックアップしたりできます。これにより、問題が発生した場合でも、いつでもデータ セットを別のバージョンに復元できます。

RDB は災害復旧に非常に適しています。ファイルは 1 つだけで、内容は非常にコンパクトで、(暗号化後に) 他のデータセンターや Amazon S3 に転送できます。

RDB は Redis のパフォーマンスを最大化できます。RDB ファイルを保存するときに親プロセスが行う必要があるのは、子プロセスをフォークアウトすることだけです。その後、子プロセスがその後のすべての保存作業を処理します。親プロセスはディスク I/O 操作を実行する必要がありません。

RDB は、大規模なデータ セットを復元する場合、AOF よりも高速です。

RDB の欠点

サーバー障害時のデータ損失を最小限に抑える必要がある場合、RDB は向きません。 Redis では、さまざまなセーブポイントを設定して RDB ファイルを保存する頻度を制御できますが、RDB ファイルはデータセット全体の状態を保存する必要があるため、これは簡単な操作ではありません。したがって、少なくとも 5 分に 1 回は RDB ファイルを保存できます。この場合、障害が発生すると、数分間のデータが失われる可能性があります。

RDB が保存されるたびに、Redis は子プロセスを fork() する必要があり、子プロセスが実際の永続化作業を実行します。データ セットが大きい場合、fork() は非常に時間がかかり、サーバーが特定のミリ秒以内にクライアントの処理を停止する可能性があります。データ セットが非常に大きく、CPU 時間が非常に厳しい場合は、この停止時間が長くなる可能性があります。もっと長くても、まるまる1秒間。 AOF書き換えにもfork()が必要ですが、AOF書き換えの実行間隔がどれだけ長くてもデータの耐久性が損なわれることはありません。

AOF ナレッジ ポイント

AOF の利点

AOF 永続性を使用すると、Redis の耐久性が非常に高くなります (耐久性が大幅に向上します)。 fsync なし、1 秒に 1 回の fsync、書き込みコマンドが実行されるたびに fsync を実行するなど、さまざまな fsync 戦略を設定できます。 AOF のデフォルト ポリシーは、fsync を 1 秒に 1 回実行することですが、この構成でも Redis は良好なパフォーマンスを維持でき、障害が発生した場合でも、失われるデータは最大 1 秒だけです (fsync はバックグラウンド スレッドで実行されます)。そのため、メインスレッドはコマンド要求の処理に懸命に取り組み続けることができます)。

AOF ファイルは追加操作のみを実行するログ ファイル (追加のみのログ) であるため、何らかの理由でログに不完全なコマンドが含まれている場合でも、AOF ファイルへの書き込みにはシークは必要ありません。(たとえば、書き込み中にディスクがいっぱいになった、書き込みが途中で停止したなど）場合でも、redis-check-aof ツールを使用してこの問題を簡単に解決できます。

Redis は、AOF ファイルのサイズが大きくなりすぎると、バックグラウンドで AOF を自動的に書き換えることができます。書き換えられた新しい AOF ファイルには、現在のデータ セットを復元するために必要な最小限のコマンド セットが含まれています。 Redis は新しい AOF ファイルの作成プロセス中に既存の AOF ファイルにコマンドを追加し続けるため、書き換え操作全体は完全に安全です。書き換えプロセス中にシャットダウンが発生した場合でも、既存の AOF ファイルは失われません。 。新しい AOF ファイルが作成されると、Redis は古い AOF ファイルから新しい AOF ファイルに切り替えて、新しい AOF ファイルへの追加を開始します。

AOF ファイルには、データベース上で実行されたすべての書き込み操作が順序どおりに保存されます。これらの書き込み操作は Redis プロトコルの形式で保存されるため、AOF ファイルの内容は非常に簡単に読み取って分析できます。ファイル（解析）も非常に簡単です。 AOF ファイルのエクスポート (エクスポート) も非常に簡単です。たとえば、誤って FLUSHALL コマンドを実行した場合でも、AOF ファイルが上書きされていなければ、サーバーを停止し、AOF の最後にある FLUSHALL コマンドを削除するだけです。ファイルを削除し、Redis を再起動すると、データセットを FLUSHALL が実行される前の状態に復元できます。

AOF の欠点

同じデータ セットの場合、通常、AOF ファイルのサイズは RDB ファイルのサイズよりも大きくなります。

使用される fsync 戦略によっては、AOF は RDB よりも遅くなる可能性があります。通常の状況では、1 秒あたりの fsync パフォーマンスは依然として非常に高く、fsync をオフにすると、負荷が重い場合でも AOF を RDB と同じ速度にすることができます。ただし、RDB は、巨大な書き込み負荷を処理する場合に、より保証された最大レイテンシを提供できます。

AOF には過去にこのようなバグがありました。個別のコマンドのせいで、AOF ファイルをリロードすると、データ セットを保存時の元の状態に復元できなくなりました。 (たとえば、ブロッキング コマンド BRPOPLPUSH はかつてそのようなバグを引き起こしました。) この状況に備えてテストがテスト スイートに追加されました。ランダムで複雑なデータ セットを自動的に生成し、これらのデータをリロードして、すべてが正常であることを確認します。この種のバグは AOF ファイルでは一般的ではありませんが、それに比べて、RDB でこの種のバグが発生することはほとんどありません。

Redis 関連の技術記事の詳細については、Redis チュートリアル 列にアクセスして学習してください。

以上がどの永続化戦略が Redis に適していますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。