[図の可動が示す] Redisのは、RDB / AOF詳細練習を永続します

Redisのは、オープンソース（BSDライセンス）、データベース、キャッシュ、およびメッセージング・ミドルウェアとして使用することができるメモリ・システムに格納されたデータ構造です。それは、このような文字列、チェーン、セット、などをハッシュなどのデータ型をサポートし、またソートの様々なサポートは非常に豊富です。

持続性とは何ですか？

次のように文は、永続的にまとめることができる：永続的記憶装置に格納する（例えば、メモリ・オブジェクト）データを保存します。持続性は、主要なデータベース内のアプリケーション、またはディスクファイル、XMLデータファイル、およびその記憶メモリに格納されたオブジェクトの上にあります。

アプリケーション層とシステム層理解永続から

それと同時に、また、アプリケーション層とシステム層からの2つのレベルが持続性を理解します。

アプリケーション層：あなたは（閉じた場合 Close ）、アプリケーションを再起動し、以前のデータが残っています。

システム層：あなたが閉じた場合は（ Shutdown ）、あなたのシステム（コンピュータ）とは、前のデータがまだそこにある再起動してください。

なぜRedisの持続性？

Redisのデータ型は、削除/追加し、交差点や労働組合、その差よりリッチな操作で、プッシュ/ポップでサポートされており、これらの操作はアトミックです。これに基づき、Redisのは、並べ替えの異なるさまざまな方法をサポートしています。Memcachedのと同じように、効率性を確保するために、データはメモリにキャッシュされています。

はい、データはあなたがシステムをシャットダウンすると、メモリにキャッシュされたか、システムを再起動され、データがメモリにキャッシュされて消えてしまいます、取り戻すことはありません。そのため、データの長期保存を行うためには、Redisのデータキャッシュは永続ストレージを行う置くことが必要です。

永続性を達成するためにどのようにRedisの？

初期の設計では、Redisのは、アカウントにこの問題を取られています。公式には、データの永続化の方法の種々の異なるレベルを提供しています：

1、RDB永続的には、指定した時間間隔は、データのスナップショットを保存することができます。

2、AOF元のデータを復元するために、これらのコマンドを再実行するサーバーの再起動は、AOFは.Redisファイルのことができます最後に、追加のプロトコルのRedisに各書き込み操作を保存するためのコマンドサーバーへの各書き込み操作記録の永続音量が大きすぎないでしょうAOFファイルになるようにAOFは、バックグラウンド上のファイルを上書きします。

あなたのデータは、サーバが実行されている場合にのみ存在する場合は3、あなたは任意の永続的な方法を使用することはできません。

4は、RDBより設定されたファイルデータAOF通常の状況下で貯蔵としてのRedisは、元のデータを復元するために、優先度負荷AOFファイルを再起動すると、この場合、同時に持続性の二種類にも開くことができファイルデータは、完了するまでに設定します。

あなたは選択の持続的なレベルは、その後、我々は方法のAOFとRDBの道、差異の種類、およびどのようなそれぞれの長所と短所を見て開始するどの方法がわからない場合は、完成した学習後、再び選択肢を検討しています種レベル。

比較優位RDBの方法AOF方法

まず、2つの方法で説明した欠点を見てみましょう、のは、公式の説明については、次の2つの方法の利点を見て比較してみましょう。

道のRDBの利点

RDBは、毎日過去30日間を維持しながら、あなたは、タイムズのそれぞれに過去24時間のデータを保存することができるものとして、バックアップ・データ・セットのための理想的な時間データ収集における特定のポイントを保持している、非常にコンパクトなファイル、、、ですデータ、問題はあなたが需要に応じて設定されたデータの異なるバージョンに復元することができても、そのようにします。
RDBは、簡単に災害復旧のための理想的な、別のリモートデータセンターに転送され、コンパクトで、単一のファイルです。
RDB永続的な方法は、Redisののパフォーマンスを最大化するように、あなたは親のみが行う必要保存RDB RDBファイルには、フォーク、子によって行われるすべての作業は、親が他のIO操作を行うために必要とされていない子プロセスであり、。
AOF、より高速な大規模なデータセットを復元し、RDBの方法と比較すると。

Redisのは、保存する必要がある場合は dump.rdb 、ファイルを、サーバーは次の処理を行います。

Redisの呼び出しフォーク。親と子プロセスの両方を持っています。
子プロセス・データ・セットは、一時ファイルのRDBに書き込まれます。
子プロセスは新しいRDBファイルの書き込みを完了した場合、Redisのは、新しいRDB RDBファイルと元のファイルを置き換え、古いファイルRDBを削除します。

作業のこの方法は、Redisのは、（書き込みからコピーすることができますcopy-on-writeメカニズムの利益のために）。

道のAOFの利点

AOFは、より耐久性のRedisのご利用を行います。

你可以使用不同的 fsync 策略：无 fsync、每秒 fsync 、每次写的时候 fsync .使用默认的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据。
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

优点对比总结

RDB 方式可以保存过去一段时间内的数据，并且保存结果是一个单一的文件，可以将文件备份到其他服务器，并且在回复大量数据的时候，RDB 方式的速度会比 AOF 方式的回复速度要快。

AOF 方式默认每秒钟备份1次，频率很高，它的操作方式是以追加的方式记录日志而不是数据，并且它的重写过程是按顺序进行追加，所以它的文件内容非常容易读懂。可以在某些需要的时候打开 AOF 文件对其编辑，增加或删除某些记录，最后再执行恢复操作。

RDB 方式与 AOF 方式的缺点对比

RDB 方式的缺点

如果你希望在 Redis 意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么 RDB 不适合你.虽然你可以配置不同的save时间点(例如每隔 5 分钟并且对数据集有 100 个写的操作),是 Redis 要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在 Redis 意外宕机,你可能会丢失几分钟的数据。
RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候, fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且 CPU 性能不是很好的情况下,这种情况会持续1秒, AOF 也需要 fork ,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

AOF 方式的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

缺点对比总结

RDB 由于备份频率不高，所以在回复数据的时候有可能丢失一小段时间的数据，而且在数据集比较大的时候有可能对毫秒级的请求产生影响。

AOF 的文件提及比较大，而且由于保存频率很高，所以整体的速度会比 RDB 慢一些，但是性能依旧很高。

工作原理

コピーオンライトメカニズムをうまく利用しているようAOF書き換えやRDB、スナップショットを作成します。

Redisのは、フォークを（）を実行し、現在親プロセスと子プロセスの両方を持っています。
新しい子プロセスの内容は、一時ファイルに書き込まれAOFファイルを開始しました。
これらの変更は、既存のファイルAOFに追加する一方、すべての新しい書き込みコマンドの実行のために、親プロセス彼らも、既存のファイルAOFダウン途中で書き換えるのこの種では、メモリー・キャッシュに蓄積しながら、まだ安全。
子プロセスが完全に書き直した作品である場合、それは新しいAOFファイルの最後に、キャッシュメモリ内の追加データのすべてを、信号を受信した後、親プロセスに親プロセスがシグナルを送ります。
すべてのコマンドは、新しいAOFファイルの末尾に直接追加されます後に今のRedisはアトミックに、新しいファイルと古いファイルを置き換えます。

達成するために実践し、RDBとAOF

RDB方法持続的でオープンな構成

Redisの永続性モードがデフォルトのRDBで、デフォルトで有効になっています。RDBは、アクティブおよびパッシブ保全保全に分かれて保存する方法があります。イニシアチブを保存でのRedis-CLIで入力することができます save に、受動的な保全、現在の公式のデフォルトのトリガ条件をすることができ、設定ファイルで設定されたトリガ条件を満たすために必要 redis.conf で見ます：

save 900 1
save 300 10
save 60 10000
复制代码

その意味は次のとおりです。

服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000次修改。
复制代码

トリガ条件が満たされた後、データが正確にこのために、スナップショットとして保存されますこれは、RDBのデータの整合性がAOFよりも小さくなっていると言います。

保管条件をトリガした後、中に名前の指定されたディレクトリが生成されます dump.rdb 、ファイルをあなたはRedisの次回起動時まで待って、Redisのは、ディレクトリに読み取りに行く dump.rdb のRedisにデータをリストアれる、ファイル。

それは、このディレクトリにはどこにありますか？

私たちは、クライアントでコマンドを入力することができますconfig get dirビュー：

gannicus@$ src/redis-cli
127.0.0.1:6379> config get dir
1) "dir"
2) "/home/gannicus/Documents/redis-5.0.0"
127.0.0.1:6379> 
复制代码

結果を返します"/home/gannicus/Documents/redis-5.0.0"保存する dump.rdb ディレクトリを。

Redisの奥付

試験の前に、前提を説明します。redis 直接公式サイトからアーカイブ、ダウンロードし解凍する redis-x.x.x フォルダを、私があったような redis-5.0.0、そのフォルダを入力し、 redis-5.0.0 プロジェクトのルートディレクトリの使用makeをインストールするコマンドを。

RDBテストを保存するには、受動的トリガー

ただ、それは保存するようにアクティブとパッシブの引き金に分け言及し、そして今、私たちは受動的トリガーをテストする必要があります。まず起動 redis-serverして、クライアントを開いて redis-cli 、いくつかのレコードを追加します：

127.0.0.1:6379> set lca 1
OK
127.0.0.1:6379> set lcb 1
OK
127.0.0.1:6379> set lcc 1
OK
127.0.0.1:6379> set lcd 1
OK
127.0.0.1:6379> set lce 1
OK
127.0.0.1:6379> set lcf 1
OK
127.0.0.1:6379> set lcg 1
OK
127.0.0.1:6379> set lch 1
OK
127.0.0.1:6379> set lci 1
OK
127.0.0.1:6379> set lcj 1
OK
127.0.0.1:6379> set lck 1
OK
127.0.0.1:6379> set lcl 1
OK
127.0.0.1:6379> set lcm 1
OK
复制代码

私たちは、13のレコードの合計を加算し、見ることができます：

127.0.0.1:6379> keys *
 1) "lca"
 2) "lcd"
 3) "lcg"
 4) "lce"
 5) "lcb"
 6) "lcm"
 7) "lcf"
 8) "lci"
 9) "lcl"
10) "lcc"
11) "lck"
12) "lcj"
13) "lch"
127.0.0.1:6379> 
复制代码

そして、見つかったredis-serverログウィンドウの終わりには、次のヒントを表示されます。

21971:M 21 Oct 2018 16:52:44.062 * 10 changes in 300 seconds. Saving...
21971:M 21 Oct 2018 16:52:44.063 * Background saving started by pid 22552
22552:C 21 Oct 2018 16:52:44.066 * DB saved on disk
21971:M 21 Oct 2018 16:52:44.165 * Background saving terminated with success
复制代码

英語・プロンプトから内容について読むことができる、それは記録が10秒300を変更されたことを検出し、私たちはデータレコード13を追加し、満たす redis.conf RDBに格納されたデータのための条件、ここで実行されるデータ保持の操作をし、アウトヒントプロセスは22552は、保存操作を開け、そして最終的に成功し、保存するように要求します。

そして、しているディレクトリ内の参照 dump.rdb ファイルが生成されました。

今Redisのプロセスのkill、どのようなデータが保存されますか？

コマンド kill -9 pid （pidはプロセスIDです）シミュレーションRedisの予期せず終了し、その後のRedisを起動し、私たちは、見て終わりにのみ、すべての保存10回のまたは13の記録を保存しますか？

127.0.0.1:6379> keys *
 1) "lcb"
 2) "lcj"
 3) "lcd"
 4) "lch"
 5) "lci"
 6) "lcc"
 7) "lcf"
 8) "lce"
 9) "lca"
10) "lcg"
127.0.0.1:6379> 
复制代码

ビューの再起動レコードとのみ10レコード内の13件のレコードがまた壊れた瞬間は、トリガ条件であることを起こるが下に満たされない限り、信頼できない以前に述べたように、データの整合性RDBのアプローチを確認した、保存されますました番号。

閉じるRDB

ちょうどあなたがそれを設定ファイルにコメントアウトこれら三つを設定し、追加することができます必要がない場合には、デフォルトで有効になって、言及 save ""します：

  save ""
# save 900 1
# save 300 10
# save 60 10000
复制代码

ダース以上のレコードを追加していき、その後、有効にする設定ファイルRedisのサービスを保存した後に再起動する必要があります：

127.0.0.1:6379> keys *
 1) "lcb"
...
23) "lca"
24) "lcg"
127.0.0.1:6379> 
复制代码

私はそれ以上14件のレコードを行く前に、既存の10に基づき、経由同じことがkill近く、予想外のRedisをシミュレートし、データも保存されているかどうかを確認するためにサービスを開始します。

127.0.0.1:6379> keys *
 1) "lcb"
 2) "lcj"
 3) "lcd"
 4) "lch"
 5) "lci"
 6) "lcc"
 7) "lcf"
 8) "lce"
 9) "lca"
10) "lcg"
127.0.0.1:6379> 
复制代码

これは、データを回復するための時間が直前に10を回復し、14件のレコードが保存されていない再び追加見つかりました。そして節約のヒントをトリガ以前のように見つけることができませんでした、Redisのサーバーのログ・ウィンドウを観察し、実証済みの方法RDBは閉じられています。

テストを保存するにはRDBの取り組み

ファイルを設定することで、彼らは力にそれを入力した場合、その後にシャットダウンするためのイニシアチブをとる、受動的なトリガーを閉じていますか？

よるRedisのクライアント（Redisの-CLI）でdelいくつかのレコードのコマンドを削除し、enter save保存操作を実行するコマンドを：

127.0.0.1:6379> keys *
 1) "lcc"
 2) "lch"
 3) "lcb"
 4) "lci"
 5) "lce"
 6) "lcj"
 7) "lcg"
 8) "lca"
 9) "lcd"
10) "lcf"
127.0.0.1:6379> del lca lcb lcc
(integer) 3
127.0.0.1:6379> save
OK
127.0.0.1:6379> 
复制代码

あなたは見ることができるredis-server新しいログヒント：22598:M 21 Oct 2018 17:22:31.365 * DB saved on diskそれはデータが保存されていることを教えてくれる。

だから、その後、実際には、これらのアクションを保存したかどうかを確認するためにサービスを開き、異常閉じシミュレートし続けます：

127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379> 
复制代码

確かに、これらの欠失が保存されている、それはプロファイルをシャットダウンするためのイニシアチブに影響されない証明する3つのレコードを持っていないデータを回復します。

また、saveそれを保存する方法は他にありますか。

bgsaveを保存し、保存します

いくつかは、Redisのの提供save及びbgsave保存のこれら二つの異なる方法、および2つの方法がときの実行と呼ばれるrdbSave機能が、それらは異なる方法で呼び出されます。

save ダイレクトコール rdbSave保存が完了するまで、メインRedisのプロセスをブロックし、方法を。ブロックされたメインプロセス中に、サーバーは、任意のクライアント要求を処理することはできません。
bgsave フォーク子プロセスは、子プロセスは呼び出し元の責任で rdbSave あり、保存が完了した後に完了した旨の通知を保存し、メインプロセスにシグナルを送ります。以来 rdbSave 、子プロセスで呼び出されるので、Redisのサーバー bgsave の実行中は、クライアントの要求を処理し続けることができます。

save 同期、あるbgsave 非同期操作が。

bgsave使用方法やコマンドsaveのコマンド方式を使用しても同じです。

127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379> del lci lcj 
(integer) 2
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> keys *
1) "lcd"
2) "lcg"
3) "lcf"
4) "lce"
5) "lch"
127.0.0.1:6379> 
复制代码

シャットダウンを保存

実際には、shutdownこのコマンドは、データを保存することができ、驚きは驚きではありません。それは偶然ではないという意味、閉鎖前にデータを保存するのだろうか？

127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> keys *
1) "apps"
2) "lcd"
3) "lcg"
4) "lcf"
5) "app"
6) "lce"
7) "lch"
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$ 
复制代码

そして、Redisのサービスが遮断されました。私たちは、効果かどうかを確認するために、クライアントにRedisのサービスを再起動する必要があります。

gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lcf"
3) "lcd"
4) "lch"
5) "lcg"
复制代码

でも有効にならない、とげは刺激しませんか？これはなぜでしょうか？もちろん、公式文書のシャットダウンが唯一の出口が保存されますと言う、あなたは〜うそ

私たちは、文書があることに注意してください

突然で持続した場合にオープンすることに気づいshutdownたコマンドが、それは設定ファイル内のいくつかのものに、その後、データを失うことはありません閉じてsave、それを開くために、設定項目の：

#   save ""
save 900 1
save 300 10
save 60 10000
复制代码

そして、Redisのサービスをオンにし、再度試してみてください（プロセス：追加 - >シャットダウン - >再起動サービス - >表示）：

127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lch"
3) "app" 4) "lcf" 5) "apps" 6) "lcd" 7) "lcg" 127.0.0.1:6379> 复制代码

彼は最終的に考え出しました。

AOF方法持続的でオープンな構成

オープンAOF

AOFはデフォルトでオンになっていない、とあなたが有効にする場合は、する必要が redis.conf 開いて、開いているファイルを設定します redis.conf：

$ vim redis.conf
复制代码

次に、ファイルで見つかった appendonly と no 読んで yes：

appendonly yes
复制代码

これは、AOFの永続性を開くための方法です。

同期モードを設定します

AOFはまた、いくつかの同期モードをサポートし、彼らは以下のとおりです。

appendfsync always  # 每次有数据修改发生时都会写入AOF文件（安全但是费时）。
appendfsync everysec  # 每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no  # 从不同步。高效但是数据不会被持久化。
复制代码

デフォルトの設定では everysec、あなたは需要に応じて調整することができ、ここで私は設定を変更します always：

appendfsync always
# appendfsync everysec
# appendfsync no
复制代码

カスタムAOFレコードファイル名

コンフィギュレーションに表示されているようにRedisのは、デフォルトのファイル名で提供されます。

appendfilename "appendonly.aof"
复制代码

あなたはまた、例えば、別のファイル名を指定することができ、それはデフォルトの名前を維持させることができます。

appendfilename "RNGLetme.aof"
复制代码

ウィル appendonly 、 appendfsync および appendfilename 設定し、保存します。Redisのサービスを再起動します。

$./redis-server
复制代码

コマンドは、 ls 名前付きに新たな命を見ることができ、ローカルのファイルを表示する RNGLetme.aof ファイルは、使用することができます：

$cat RNGLetme.aof  
复制代码

内部の内容を表示するには、データの変更に伴う、現在行われていない、それが空白になっています。

そして、Redisのクライアントを開きます。

$./redis-cli
复制代码

そして、複数のデータレコードを追加します。

127.0.0.1:6379> set rng lpl
OK
127.0.0.1:6379> set ig lpl
OK
127.0.0.1:6379> set edg lpl
OK
127.0.0.1:6379> keys *
1) "edg"
2) "rng"
3) "ig"
127.0.0.1:6379> 
复制代码

正常に追加見ることができ rng、edg、ig これらの3つのレコードは、次に開く RNGLetme.aof レコードの内部を見る、ファイルを：

*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
复制代码

追加されるたびにデータが記録されています。

それは、削除操作がない場合には、それが記録されますか？

127.0.0.1:6379> del edg
(integer) 1
127.0.0.1:6379> keys *
1) "rng"
2) "ig"
127.0.0.1:6379> 
复制代码

削除操作の後、その後を見て RNGLetme.aof 、ファイル内のレコード：

*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
*2
$3
del
$3
edg
复制代码

コントラストを記録する前に、新しい del edg オペレーティング記録。これは、AOFの前の説明を確認：双方向データの変更のログが記録されています。

AOFの復旧テスト

ここでもによって kill 異常shutdownコマンドRedisのをシミュレートします：

gannicus@$ kill -9 22645
复制代码

そして、Redisのサービスを再起動します。

$ src/redis-server redis.conf
复制代码

次に、これらのデータがあるかどうか、クライアントから見てみましょう：

$ src/redis-cli
127.0.0.1:6379> keys *
1) "ig"
2) "rng"
复制代码

見て、することができます rng し、 ig それは持続力であることを意味し、まだです。

AOFの道にRDBの道から切り替える方法

Redisのバージョン2.2以上では、AOFにRDBから切り替えることなく再開することができます。

最新dump.rdbファイルのバックアップコピーを作成し、安全な場所にバックアップされます。次の2つのコマンドを実行します。

redis-cli config set appendonly yes
redis-cli config set save “”
复制代码

書き込みコマンドが正常に終了AOFファイルに追加されていることを確認してください。最初のコマンドが開きますAOFの特徴：ファイルが作成されるまでのRedisは、要求コマンドの処理を継続し、終了AOFファイルに追加書き込みコマンドを開始します後Redisのは、初期AOFが完了するまでブロックします。

RDBを閉じるための第二のコマンド実行機能。このステップは、あなたが好むならば、あなたも同時にRDBとAOF両方の持続性の機能を使用することができ、任意です。

重要：别忘了在 redis.conf 中打开 AOF 功能！否则服务器重启后，之前通过 CONFIG SET 命令设置的配置就会被遗忘，程序会按原来的配置来启动服务器。

优先选择 RDB 还是 AOF 呢？

分析对比两种方式并做了测试后，发现这是两种不同风格的持久化方式，那么应该如何选择呢？

对于企业级的中大型应用，如果不想牺牲数据完整性但是又希望保持高效率，那么你应该同时使用 RDB 和 AOF 两种方式；
如果你不打算耗费精力在这个地方，只需要保证数据完整性，那么优先考虑使用 AOF 方式；
RDB 方式非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

备份redis数据的建议

确保你的数据有完整的备份，磁盘故障、节点失效等问题问题可能让你的数据消失不见，不进行备份是非常危险的。

Redis 对于数据备份是非常友好的，因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建，就不会进行任何修改。当服务器要创建一个新的 RDB 文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。

这也就是说，无论何时，复制 RDB 文件都是绝对安全的。

创建一个定期任务（ cron job ），每小时将一个 RDB 文件备份到一个文件夹，并且每天将一个 RDB 文件备份到另一个文件夹。
确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用 find 命令来删除过期的快照：比如说，你可以保留最近 48 小时内的每小时快照，还可以保留最近一两个月的每日快照。
至少每天一次，将 RDB 备份到你的数据中心之外，或者至少是备份到你运行 Redis 服务器的物理机器之外。

Redis 密码持久化

在 Redis 中数据需要持久化，密码也要持久化。在客户端通过命令：

config set requirepass zxc9527
复制代码

可以为 Redis 设置值为zxc9527的密码，但是当 Redis 关闭并重新启动后，权限验证功能就会失效，再也不需要密码。所以，密码也需要在 redis.conf 中持久化。打开 redis.conf 找到 requirepass 配置项，取消其注释并在后面设置密码：

requirepass zxc9527
复制代码

保存后重启 Redis 服务，密码持久化即生效。

转自：https://juejin.im/post/5bcab6f46fb9a05d3c802ea6

永続化機構のRedis