Memcache などの他のキャッシュ製品と比較すると、Redis は単純なキーと値の型のデータだけでなく、list、set、zset もサポートしているという点で明らかな利点があります。ハッシュなどのデータ構造の保存。 2 回の記事でこれらの豊富なデータ型を詳しく紹介しましたが、次に、Redis のもう 1 つの大きな利点である永続性を紹介します。 (推奨: redis ビデオ チュートリアル )
Redis はインメモリ データベースであるため、いわゆるインメモリ データベースとは、データベースの内容をメモリに保存することを意味します。コンテンツをハードディスクに直接保存する従来のデータベースと比較して、インメモリ データベースの読み取りと書き込みの効率は、従来のデータベースの読み取りと書き込みの効率 (メモリの読み取りと書き込みの効率) よりもはるかに高速です。ハードディスクの読み取りおよび書き込み効率よりもはるかに優れています)。ただし、メモリに保存すると、電源が切れたり、コンピュータがダウンしたりすると、メモリデータベース内のデータがすべて失われます。
この欠点を解決するために、Redis はメモリ データをハードディスクに永続化し、永続ファイルを使用してデータベース データを復元する機能を提供します。 Redis は 2 つの形式の永続性をサポートしています。1 つは RDB スナップショット (スナップショット)、もう 1 つは AOF (ファイル追加) です。このブログではまずRDBスナップショットについて紹介します。
1. RDB の概要
RDB は、Redis が永続化のために使用するメソッドであり、現在メモリ内にあるデータ セットのスナップショットです。ディスクに書き込みます。つまり、スナップショットのスナップショット (データベース内のすべてのキーと値のペアのデータ)。リカバリ中、スナップショット ファイルはメモリに直接読み込まれます。
トップに戻る
2. トリガー方法
RDB には、自動トリガーと手動トリガーという 2 つのトリガー方法があります。
①、自動的にトリガーします
redis.conf 設定ファイルの SNAPSHOTTING の下で、
①、保存します。これは、トリガーを構成するために使用されます。 RedisのRDB永続条件、つまりメモリ上のデータをいつハードディスクに保存するか。たとえば、「m n を保存」などです。データセットが m 秒以内に n 回変更されると、bgsave が自動的にトリガーされることを示します (このコマンドは以下で紹介され、RDB 永続性を手動でトリガーするコマンドも紹介されます)
デフォルトの構成は次のとおりです:
save 900 1:表示900 秒内如果至少有 1 个 key 的值变化,则保存 save 300 10:表示300 秒内如果至少有 10 个 key 的值变化,则保存 save 60 10000:表示60 秒内如果至少有 10000 个 key 的值变化,则保存
もちろん、Redis のキャッシュ機能を使用するだけで永続化が必要ない場合は、すべての保存行をコメントアウトして保存機能を無効にすることができます。空の文字列を直接使用して非アクティブ化を行うことができます: save ""
②, stop-writes-on-bgsave-error: デフォルト値は yes です。 RDB が有効で、最後のデータのバックグラウンド保存が失敗した場合、Redis がデータの受信を停止するかどうか。これにより、データがディスクに正しく保存されていないことがユーザーにわかります。そうしないと、障害が発生したことに誰も気づかなくなります。 Redis が再起動すると、再びデータの受信を開始できます
③、rdbcompression; デフォルト値は yes です。ディスクに保存されるスナップショットについては、保存するために圧縮するかどうかを設定できます。その場合、redis は圧縮に LZF アルゴリズムを使用します。圧縮に CPU を消費したくない場合は、この機能をオフに設定できますが、ディスクに保存されるスナップショットのサイズは大きくなります。
④、rdbchecksum: デフォルト値はyesです。スナップショットを保存した後、Redis に CRC64 アルゴリズムを使用させてデータ検証を行うこともできますが、これによりパフォーマンスの消費が約 10% 増加します。パフォーマンスを最大限に向上させたい場合は、この機能をオフにすることができます。
⑤、dbfilename: スナップショットのファイル名を設定します。デフォルトは dump.rdb
⑥、dir: スナップショット ファイルのストレージ パスを設定します。この構成項目はディレクトリである必要があります。ファイル名ではありません。デフォルトでは、現在の構成ファイルと同じディレクトリに保存されます。
つまり、設定ファイルに設定したsaveメソッドにより、実際の操作が設定形式を満たすとRDB永続化が実行され、現在のメモリスナップショットがdirで設定されたディレクトリに保存されます。ファイル名は、設定された dbfilename によって決まります。
②. 手動トリガー
RDB 永続化のために Redis を手動でトリガーするには 2 つのコマンドがあります:
1. save
このコマンドは現在の Redis をブロックします。サーバーでは、save コマンドの実行中、RDB プロセスが完了するまで Redis は他のコマンドを処理できません。
明らかに、このコマンドは比較的大きなメモリを持つインスタンスに対して長期的なブロックを引き起こしますが、これは致命的な欠陥です。この問題を解決するために、Redis は 2 番目の方法を提供します。
2. bgsave
このコマンドを実行すると、Redis はバックグラウンドでスナップショット操作を非同期に実行し、スナップショットはクライアントの要求に応答することもできます。具体的な操作としては、Redis プロセスが fork 操作を実行して子プロセスを作成し、RDB 永続化プロセスが子プロセスを担当し、完了後に自動的に終了します。ブロッキングはフォークフェーズ中にのみ発生し、通常は非常に短期間です。
基本的に、Redis 内のすべての RDB 操作は bgsave コマンドを使用します。
ps:lushall コマンドを実行すると dump.rdb ファイルも生成されますが、これは空で意味がありません
3. データの復元 #
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间,会一直处于阻塞状态,直到载入工作完成为止。
获取 redis 的安装目录可以使用 config get dir 命令
4、停止 RDB 持久化
有些情况下,我们只想利用Redis的缓存功能,并不像使用 Redis 的持久化功能,那么这时候我们最好停掉 RDB 持久化。可以通过上面讲的在配置文件 redis.conf 中,可以注释掉所有的 save 行来停用保存功能或者直接一个空字符串来实现停用:save ""
也可以通过命令:
redis-cli config set save " "
回到顶部
5、RDB 的优势和劣势
①、优势
1.RDB是一个非常紧凑(compact)的文件,它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2.生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
②、劣势
1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作(内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑),频繁执行成本过高(影响性能)
2、RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
3、在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改(数据有丢失)
回到顶部
6、RDB 自动保存的原理
Redis有个服务器状态结构:
struct redisService{ //1、记录保存save条件的数组 struct saveparam *saveparams; //2、修改计数器 long long dirty; //3、上一次执行保存的时间 time_t lastsave; }
①、首先看记录保存save条件的数组 saveparam,里面每个元素都是一个 saveparams 结构:
struct saveparam{ //秒数 time_t seconds; //修改数 int changes; };
前面我们在 redis.conf 配置文件中进行了关于save 的配置:
save 900 1:表示900 秒内如果至少有 1 个 key 的值变化,则保存 save 300 10:表示300 秒内如果至少有 10 个 key 的值变化,则保存 save 60 10000:表示60 秒内如果至少有 10000 个 key 的值变化,则保存
那么服务器状态中的saveparam 数组将会是如下的样子:
②、dirty 计数器和lastsave 属性
dirty 计数器记录距离上一次成功执行 save 命令或者 bgsave 命令之后,Redis服务器进行了多少次修改(包括写入、删除、更新等操作)。
lastsave 属性是一个时间戳,记录上一次成功执行 save 命令或者 bgsave 命令的时间。
通过这两个命令,当服务器成功执行一次修改操作,那么dirty 计数器就会加 1,而lastsave 属性记录上一次执行save或bgsave的时间,Redis 服务器还有一个周期性操作函数 severCron ,默认每隔 100 毫秒就会执行一次,该函数会遍历并检查 saveparams 数组中的所有保存条件,只要有一个条件被满足,那么就会执行 bgsave 命令。
执行完成之后,dirty 计数器更新为 0 ,lastsave 也更新为执行命令的完成时间。
更多redis知识请关注redis数据库教程栏目。
以上がRedisにおけるRDB永続化について詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。