Redis 永続化のいくつかの方法の紹介

1. はじめに

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

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

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

redis は永続化のための 2 つの方法を提供します。1 つは RDB 永続化 (原則として、メモリ内の Reid のデータベース レコードをディスク上の RDB 永続化に定期的にダンプすることです)、もう 1 つは AOF (追加のみファイル) 永続性 (原則として、Reids の操作ログを追加形式でファイルに書き込むことです)。では、これら 2 つの永続化方法の違いは何でしょうか?また、どのように選択すればよいのでしょうか?インターネットで読んだもののほとんどは、これら 2 つの方法を構成して使用する方法を紹介していますが、2 つの違いや、どのようなアプリケーション シナリオで使用されるかについては紹介されていません。

2. 2 つの違いは、

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

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

3. 2 つのメリットとデメリット

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 には、より結果的に一貫した意味があります。

4. 一般的に使用される構成

RDB 永続化構成

Redis は、ダンプするデータ セットのスナップショットをダンプします。ファイル内のrdb。さらに、構成ファイルを使用して Redis サーバー ダンプ スナップショットの頻度を変更することもできます。6379.conf ファイルを開いた後、save を検索すると、次の構成情報が表示されます:

save 900 1 #At 900 秒 (15 分) 後、少なくとも 1 つのキーが変更された場合は、メモリ スナップショットをダンプします。

save 300 10 #300 秒 (5 分) 後、少なくとも 10 個のキーが変更された場合は、メモリ スナップショットをダンプします。

save 60 10000 #60 秒 (1 分) 後、少なくとも 10000 個のキーが変更された場合は、メモリ スナップショットをダンプします。

AOF 永続化構成

Redis 構成ファイルには 3 つの同期メソッドがあります。

appendfsync always #Every time there is Whenever data変更が発生すると、AOF ファイルに書き込まれます。

appendfsync eachsec #1 秒ごとに 1 回同期します。このポリシーは AOF のデフォルトのポリシーです。

appendfsync no #同期しない。効率的ですが、データは保持されません。

redis についてさらに詳しく知りたい場合は、redis データベース チュートリアル 列に注目してください。

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