Redis の永続性とマスタースレーブレプリケーションを 10 分で徹底的に理解する

Redis の永続性とは何ですか?

Redis は、キーと値のインメモリデータベース (NoSQL) です。すべてのデータはメモリに保存されます。クライアント要求を処理する場合、以下に示すように、すべての操作はメモリ内で実行されます。

こうすることで何が問題になるのでしょうか?

実際、基本的なコンピューターの知識が少しでもあれば、サーバーがシャットダウンされると（さまざまな理由で）メモリに保存されたデータは消えてしまうことは誰でも知っています。サーバーのシャットダウンによってデータが消えるだけでなく、Redis サーバーデーモンが終了するとメモリ内のデータも消えてしまいます。

Redis をキャッシュとしてのみ使用するプロジェクトの場合、データの消失は大きな問題にならない可能性があります。データソースからデータを再ロードするだけです。ただし、ユーザーから送信された業務データを直接 Redis に保存し、Redis を重要な業務データを保存するデータベースとして使用する場合、Redis のメモリデータ損失の影響は壊滅的なものになる可能性があります。メモリ内でのデータ損失を回避するために、Redis は永続性のサポートを提供します。データを永続化できるように、メモリからハードディスクにデータを保存するさまざまな方法を選択できます。

Redis は、RDB と AOF という 2 つの異なるデータ永続化方法を提供します。これらのさまざまな永続化方法を詳しく紹介しましょう。

翻訳データベース

RDB はスナップショットストレージの永続化方式です。具体的には、ある瞬間のRedisのメモリデータをハードディスク上のファイルに保存します。デフォルトの保存ファイル名は dump.rdb です。 Redis サーバーが起動すると、dump.rdb ファイルのデータがメモリに再ロードされ、データが復元されます。

RDB永続モードを有効にする

RDB 永続性を有効にするのは非常に簡単です。クライアントは、Save コマンドまたは bgsave コマンドを Redis サーバーに送信して、サーバーに rdb ファイルを生成させたり、サーバー構成ファイルを通じてトリガーとなる RDB 条件を指定したりすることができます。

1. 保存コマンド

保存コマンドは同期操作です。

 #データをディスクに同期する
> 保存

クライアントが永続性のためにサーバーに保存コマンド要求を送信すると、サーバーは保存コマンドの後にデータの同期が完了するまで他のクライアントからの要求をブロックします。

データ量が多すぎると、データの同期に長い時間がかかり、その間、Redis サーバーは他のリクエストを受信できなくなります。したがって、実稼働環境では save コマンドを使用しないことが最善です。

2. セーブ

save コマンドとは異なり、bgsave コマンドは非同期操作です。

 #データセットを非同期でディスクに保存する
> 保存

クライアントがサービスに bgsave コマンドを送信すると、Redis サーバーのメインプロセスは子プロセスをフォークしてデータを同期します。データを rdb ファイルに保存した後、子プロセスは終了します。

そのため、save コマンドと比較すると、Redis サーバーは bgsave を処理するときに IO 書き込みに子スレッドを使用し、メインプロセスは引き続き他の要求を受信できますが、フォークされた子プロセスは同期的であるため、子プロセスをフォークすると他の要求を受信できなくなります。つまり、子プロセスのフォークに時間がかかりすぎる場合 (通常は非常に高速)、bgsave コマンドは他のクライアントからの要求をブロックする可能性があります。

3. サーバー構成の自動トリガー

クライアント経由でコマンドを送信する方法の他に、Redis 構成ファイルの保存時に [一定秒数以内の書き込み操作の最小数] など、RDB 永続化をトリガーする条件を指定して RDB データの同期を開始するという方法もあります。

たとえば、設定ファイル redis.conf で次のオプションを指定できます。

 # 900 秒以内に少なくとも1つの書き込みコマンドが発行される
900 1 を節約
# 300秒以内に少なくとも10回の書き込みコマンド
300 10 を節約
# 60秒以内に少なくとも10,000回の書き込みコマンド
60 10000を節約

サーバーの起動時に構成ファイルが読み込まれます。

 #サーバーを起動して設定ファイルをロードします
redis - サーバーredis.conf

サーバー構成ファイルを通じて RDB をトリガーするこの方法は、bgsave コマンドに似ています。トリガー条件が満たされると、子プロセスがフォークされ、データが同期されます。ただし、トリガー時間を短く設定しすぎると、RDB ファイルへの書き込みが頻繁に行われ、サーバーのパフォーマンスに影響が出る可能性があるため、この方法で RDB 永続性をトリガーしないことをお勧めします。時間を長く設定しすぎると、データが失われます。

rdbファイル

上記では、サーバーに rdb ファイルを生成させる 3 つの方法を紹介しました。メインプロセスによって生成されるか子プロセスによって生成されるかに関係なく、プロセスは次のようになります。

一時的な rdb ファイルを生成し、データを書き込みます。
データの書き込みが完了すると、正式な rdb ファイルは一時ファイルに置き換えられます。
元の db ファイルを削除します。

RDB によって生成されるデフォルトのファイル名は dump.rdb です。もちろん、設定ファイルを通じてさらに詳細に設定することもできます。たとえば、単一のマシン上で複数の Redis サーバープロセスを起動する場合、次に示すように、ポート番号ごとに異なる rdb 名を設定できます。

 #rdbファイルを圧縮するかどうか
rdb圧縮はい

# rdbファイルの名前
dbファイル名redis - 6379.rdb

 #rdbファイル保存ディレクトリ
ディレクトリ~ /redis/

RDBのいくつかの利点

AOF 方式と比較すると、rdb ファイルを介してデータを復元する方が高速です。
RDB ファイルは非常にコンパクトで、データのバックアップに適しています。
データのバックアップは RDB を通じて実行されます。これは子プロセスによって生成されるため、Redis サーバーのパフォーマンスにほとんど影響を与えません。

RDBのいくつかの欠点

サーバーがダウンした場合、RDB を使用すると一定期間内にデータが失われます。たとえば、10 分ごとに同期を設定したり、5 分間に 1,000 回の書き込みが行われるたびに同期を設定したりした場合、トリガー条件が満たされる前にサーバーがクラッシュすると、この期間のデータは失われます。
save コマンドを使用するとサーバーがブロックされ、後続のリクエストはデータ同期が完了した後にのみ受信できるようになります。
bgsave コマンドを使用して子プロセスをフォークする場合、データの量が大きすぎるとフォークプロセスがブロックされます。さらに、フォーク子プロセスはメモリを消費します。

AOF

RDB について説明した後、Redis の別の永続化方法である AOF (追加専用ファイル) について説明します。特定の瞬間のスナップショットを保存する RDB とは異なり、AOF 永続性は、クライアントからサーバーへのすべての書き込み操作コマンドを記録し、Redis プロトコルを使用して、これらの書き込み操作をサフィックス aof でファイルの末尾に追加します。 Redis サーバーを再起動すると、aof ファイル内のコマンドが読み込まれ、実行されてデータが復元されます。

AOF持続モードを有効にする

Redis はデフォルトでは AOF 永続性を有効にしません。設定ファイルでこれを有効にして、次の redis.conf ファイルのように、より詳細な設定を行うことができます。

 # aof メカニズムを有効にする
追加のみはい

# aofファイル名
追加ファイル名「appendonly.aof」

 #書き込みポリシーは、 すべての書き込み操作が aof ファイルに保存されることを意味します。everysec または no にすることもできます。
 appendfsync 常に

# デフォルトでは aof ファイルを書き換えない
いいえ- appendfsync - オン- 書き換えなし

#ディレクトリを保存
ディレクトリ~ /redis/

3つの書き込み戦略

上記の設定ファイルでは、appendfsync オプションを通じて書き込み戦略を指定できます。選択肢は3つあります。

 appendfsync 常に
# 毎秒追加同期
# appendfsync なし

1. 常に

クライアントのすべての書き込み操作は aof ファイルに保存されます。この戦略は非常に安全ですが、書き込み操作ごとに IO 操作が必要になるため、非常に遅くなります。

2. 毎秒

appendfsync のデフォルトの書き込み戦略では、aof ファイルを 1 秒ごとに 1 回書き込むため、最大で 1 秒分のデータが失われる可能性があります。

3. いいえ

Redis サーバーは AOF ファイルへの書き込みを担当しませんが、AOF ファイルへの書き込みのタイミングはオペレーティングシステムが処理します。より高速ですが、最も安全性の低いオプションであり、推奨されません。

AOF ファイルの書き換え

AOF は、クライアントの各書き込み操作を aof ファイルの末尾に追加します。たとえば、キーに対して incr コマンドが複数回実行されると、aof は各コマンドを aof ファイルに保存するため、aof ファイルは非常に大きくなります。

 増分番号1
 増分数2
 増分番号3
 増分数4
 増分番号5
 増分番号6
 ...
 増分数100000

aof ファイルが大きすぎるため、データを復元するために aof ファイルを読み込むのに非常に時間がかかります。この問題を解決するために、Redis は aof ファイルの書き換えをサポートしています。 aof を書き換えることで、現在のデータを復元するための最小限のコマンドセットを生成できます。たとえば、上記の例の複数のコマンドは次のように書き直すことができます。

 数値を100000に設定

aof ファイルはバイナリファイルです。上記の例のように各コマンドを直接保存するのではなく、Redis 独自の形式を使用します。上記はデモンストレーション目的のみです。

書き直す2つの方法

redis.conf 設定ファイルでオプション no-appendfsync-on-rewrite を設定することで、書き換えを有効にするかどうかを設定できます。この方法では、fsync ごとに書き換えが行われるため、サーバーのパフォーマンスに影響します。したがって、デフォルト値は no であり、推奨されません。

 # デフォルトでは aof ファイルを書き換えない
いいえ- appendfsync - オン- 書き換えなし

クライアントは bgrewriteaof コマンドをサーバーに送信し、これによりサーバーが AOF を書き換えることもできます。

 # サーバーが非同期的に aof ファイルの追加コマンドを書き換えるようにする
> bgrewriteaof

aof ファイルを書き換える利点

ディスク使用量を削減するために aof ファイルを圧縮します。
aof コマンドを最小限のコマンドセットに圧縮すると、データの回復が高速化されます。

AOF ファイルの破損

aof ログファイルを書き込むときに、Redis サーバーがクラッシュすると、aof ログファイルにフォーマットエラーが発生します。 Redis サーバーを再起動すると、Redis サーバーは aof ファイルの読み込みを拒否します。以下の手順に従って、AOF を修復し、データを回復できます。

念のため、現在の aof ファイルをバックアップしてください。
redis-check-aof コマンドを使用して aof ファイルを修復します。コマンドの形式は次のとおりです。

 #AOFログファイルを修復
$ redis - チェック- aof - ファイル.aof を修正

Redis サーバーを再起動し、修復された aof ファイルをロードして、データを復元します。

AOFの利点

AOF はログファイルを追加するだけなので、サーバーパフォーマンスへの影響が少なく、RDB よりも高速で、メモリの消費量も少なくなります。

AOFの欠点

AOF によって生成されたログファイルが大きすぎます。 AFO で書き換えてもファイルサイズは非常に大きくなります。
データの復元速度は RDB よりも遅くなります。

RDB または AOF を選択しますか?

上記の紹介を通じて、RDB と AOF の長所と短所を理解しました。どうやって選ぶ？

次の表現を通じて、RDB と AOF をいくつかの側面から比較することができます。適用する際には、実際のニーズに基づいて RDB または AOF を選択する必要があります。実際、データを十分に安全にしたい場合は、両方の方法を有効にすることができます。ただし、2 つの永続化方法で同時に IO 操作を実行すると、サーバーのパフォーマンスに重大な影響が出るため、選択をしなければならない場合があります。

RDB と AOF の両方が有効になっている場合、AOF に保存されたファイルは RDB ファイルよりも完全であるため、Redis は最初に AOF ログを使用してデータを復元します。

まとめ

Redis の永続化メカニズムに関する多くの知識が上記で説明されました。実際、Redis をキャッシュサーバーとして使用するだけであれば、永続性についてまったく考慮する必要はありません。ただし、今日のほとんどのサーバーアーキテクチャでは、Redis はキャッシュサーバーとしての役割を果たすだけでなく、ビジネスデータを保存するデータベースとしても使用できます。この時点で、Redis の永続化戦略の違いと選択肢を理解する必要があります。

<<: 通信会社はVMwareと提携してテクノロジーの巨人へと変貌する