Redis を永続化するにはいくつかの方法があります

Redis は高度なキーと値のデータベースです。 memcached に似ていますが、データを永続化でき、幅広いデータ型をサポートします。文字列、リンク リスト、セット、ソート セットがあります。サーバー側でのセットの和集合、共通集合、補数（差分）の計算をサポートし、さまざまなソート機能もサポートします。したがって、Redis はデータ構造サーバーとみなすこともできます。

#Redis 内のすべてのデータはメモリに保存され、その後、時々非同期でディスクに保存されます (これは「半永続モード」と呼ばれます)。また、各データの変更も行われます。追加専用ファイル (aof) に書き込むことができます (これは「完全永続モード」と呼ばれます)。

Redis のデータはメモリ上に保存されるため、永続化が設定されていない場合、redis の再起動後にすべてのデータが失われるため、redis の永続化機能を有効にしてデータをディスクに保存する必要があります。再起動すると、その後、ディスクからデータを回復できます。

Redis は永続化のための 2 つの方法を提供します。1 つは RDB 永続化 (原則として、メモリ内の Reid のデータベース レコードをディスク上の RDB 永続化に定期的にダンプすることです)、もう 1 つは AOF (ファイルの追加のみ) です。永続化（原則として、Reids の操作ログをファイルに追記形式で書き込む）。

では、これら 2 つの永続化メソッドの違いは何でしょうか?また、どのように選択すればよいのでしょうか?

RDB 永続性とは、指定された時間間隔内でメモリ内のデータ セットのスナップショットをディスクに書き込むことを指します。実際の操作プロセスは、子プロセスをフォークし、最初にデータ セットを子プロセスに書き込みます。インポートが成功すると、以前のファイルが置き換えられ、バイナリ圧縮を使用して保存されます。

AOF 永続性は、サーバーによって処理されたすべての書き込みおよび削除操作をログ形式で記録します。クエリ操作は記録されませんが、テキストで記録されます。ファイルを開いて詳細な操作記録を確認できます。

両方の長所と短所

RDB の利点は何ですか?

1). この方法を採用すると、Redis データベース全体にファイルが 1 つだけ含まれるようになり、ファイルのバックアップに最適です。たとえば、過去 24 時間のデータを 1 時間ごとにアーカイブし、過去 30 日間のデータを毎日アーカイブすることも計画できます。このようなバックアップ戦略により、システムに致命的な障害が発生した場合でも、非常に簡単に復元できます。

2). 災害復旧には、RDB が非常に良い選択です。なぜなら、単一のファイルを簡単に圧縮して、他の記憶メディアに転送できるからです。

3). パフォーマンスを最大化します。 Redis サービス プロセスの場合、永続化を開始するときに必要なのは、子プロセスをフォークアウトすることだけであり、その後、子プロセスが永続化作業を完了するため、サービス プロセスによる IO 操作の実行を大幅に回避できます。

4). AOF機構と比較して、データセットが大きい場合にはRDBの起動効率が高くなります。

RDB の欠点は何ですか?

1). データの高可用性を確保したい場合、つまりデータ損失を最大限に回避したい場合、RDB は良い選択ではありません。スケジュールされた永続化の前にシステムがクラッシュすると、ディスクに書き込まれる時間がなかったデータが失われるためです。

2).RDB はフォーク子プロセスを通じてデータの永続化を支援するため、データ セットが大きい場合、サーバー全体が数百ミリ秒、場合によっては 1 秒間サービスを停止する可能性があります。

AOF の利点は何ですか?

1). このメカニズムにより、より高いデータ セキュリティ、つまりデータの永続性が実現します。 Redis は 3 つの同期戦略、つまり 1 秒ごとの同期、変更ごとの同期、および同期なしを提供します。実際、1 秒ごとの同期も非同期で完了し、その効率も非常に高いのですが、唯一の違いは、システムがダウンすると、この 1 秒以内に変更されたデータは失われることです。変更が同期されるたびに、それを同期永続性と考えることができます。つまり、発生したすべてのデータ変更はすぐにディスクに記録されます。予想通り、このアプローチは最も効率的ではありません。同期がないことについては、これ以上言う必要はなく、誰もが正しく理解できると思います。

2). このメカニズムはログ ファイルの書き込みに追加モードを使用するため、書き込みプロセス中にダウンタイムが発生した場合でも、ログ ファイル内の既存の内容は破壊されません。ただし、この操作でデータの半分しか書き込まず、システム クラッシュが発生しても心配しないでください。次回 Redis を開始する前に、redis-check-aof ツールを使用してデータの整合性の問題を解決できます。

3). ログが大きすぎる場合、Redis は書き換えメカニズムを自動的に有効にすることができます。つまり、Redis は変更されたデータを追加モードで古いディスク ファイルに継続的に書き込み、同時に、この期間中に実行された変更コマンドを記録する新しいファイルも作成します。したがって、書き換えスイッチングを行う際のデータの安全性をより確保することができる。

4). AOF には、すべての変更操作を記録するための明確でわかりやすい形式のログ ファイルが含まれています。実際、このファイルを通じてデータの再構築を完了することもできます。

AOF の欠点は何ですか?

1). 同じ数のデータ セットの場合、通常、AOF ファイルは RDB ファイルよりも大きくなります。大規模なデータ セットを復元する場合、RDB は AOF よりも高速です。

2). 同期戦略によっては、動作効率の点で AOF は RDB よりも遅くなることがよくあります。つまり、同期戦略の 1 秒あたりの効率は比較的高く、同期無効化戦略の効率は RDB と同等です。

この 2 つのどちらかを選択する基準は、システムがキャッシュ一貫性 (aof) の向上と引き換えにパフォーマンスをある程度犠牲にしてもよいかどうか、または書き込み操作時にバックアップを有効にしないほうがよいかどうかを確認することです。パフォーマンス、バックアップ (rdb) の前に手動で保存を実行するまで待機してください。 RDB には、より結果的に一貫した意味があります。

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