Redisの永続性メカニズム、長所と短所、正しい方法の選択方法

Redis永続化メカニズム

RDB：Redisデータベース
AOF：ファイルのみを追加

RDB

1. RDBとは

   RDB：定期的に、メモリ内のデータをディスク上の一時ファイルにスナップショットとして書き込み、復元時にスナップショットファイルをメモリに読み込みます。マシンがダウンして再起動した場合、メモリ内のデータは確実に
   失われ、dis後に復元されます。

2. バックアップと復元
   メモリバックアップ->一時ディスクファイル
   一時ファイル->メモリへの復元

3. RDBの長所と短所

   • 利点
     1. たまにバックアップ、完全バックアップ
     2. 災害復旧は簡単で、リモートで送信できます
     3. 子プロセスがバックアップされると、バックアップデータの整合性を確保するために、メインプロセスにはio操作がありません（書き込みの変更や削除はありません）。
     4. AOFと比較して、大きなファイルがある場合はすばやく再起動して復元できます
   • 不利益
     1. 障害が発生した場合、最後のバックアップデータが失われる可能性があります
     2. 子プロセスが占めるメモリの比率は親プロセスのそれとまったく同じになり、CPUに負担がかかります。
     3. スケジュールされた完全バックアップは重い操作であるため、リアルタイムバックアップ用に処理することはできません。

4. RDB構成

   1. 保存場所はredis.confでカスタマイズできます：
      /user/local/redis/working/dump.rdb

   2. 保存メカニズム：

      save 900 1 #如果1个缓存更新，则15分钟后备份
      save 300 10 #如果10个缓存更新，则5分钟后备份
      save 60 10000 #如果10000个缓存更新，则1分钟后备份 
      

      1. stop-writes-on-bgsave-error
         yes：保存プロセス中にエラーが発生した場合は、書き込み操作を停止します。
         いいえ：データに一貫性がない可能性があります。
      2. rdbcompression
         はい：rdb圧縮モードを開きます
         いいえ：閉じる、CPU損失を節約しますが、ファイルは大きくなります。理由はnginxと同じです。

   AOF

   RDBは最後にバックアップされたrdbファイルを失いますが、それは無視できます。結局のところ、それはキャッシュです。失った場合は失われます。ただし、データの整合性を追求する場合は、AOFの使用を検討してください。 。

   AOF機能

   1. ユーザーが要求した書き込み操作は、ログの形式で記録されます。書き込み操作が保存されるため、読み取り操作は記録されません。
   2. ファイルは、変更された形式ではなく、追加された形式です。
   3. Redisのaofリカバリは、実際には、追加されたファイルを最初から最後まで読み書きすることです。

   利点

   1. AOFはより耐久性があり、数秒でバックアップできます。問題が発生した場合、データの最後の1秒のみが失われるため、信頼性とデータの整合性が大幅に向上します。したがって、AOFは
      、fsync操作を使用して1回使用できます。
   2. ログの形式で追加されます。ディスクがいっぱいになると、redis-check-aofツールが実行されます。
   3. データが大きすぎる場合、redisはバックグラウンドでAOFを自動的に書き換えることができます。redisが古いファイルにログを追加し続ける場合、書き換えも非常に安全であり、クライアントの
      操作に影響を与えません。
   4. AOFログに含まれるすべての書き込み操作により、redisの分析と回復が容易になります。

   不利益

   1. 同じデータ、同じデータ、AOFはRDBよりも大きい
   2. さまざまな同期メカニズムの場合、AOFはRDBよりもわずかに低い書き込み操作のために毎秒バックアップするため、AOFはRDBよりも遅くなります。fsyncを毎秒バックアップすることに何の問題もありませ
      んが、書き込むたびにバックアップfsyncを実行すると、redisのパフォーマンスが低下します。
   3. AOFにはバグがあります。つまり、データが復元されるとデータが不完全になり、AOFはRDBほど単純ではないため、AOFはより脆弱になり、バグが発生しやすくなりますが、発生したため
      、AOFは再構築されません。古い命令に従って、代わりに、その時点でキャッシュに存在するデータ命令に従って再構築されます。これにより、より堅牢で信頼性が高くなります。

   AOF構成

   # AOF 默认关闭，yes可以开启
   appendonly no
   # AOF 的文件名
   appendfilename "appendonly.aof"
   # no：不同步
   # everysec：每秒备份，推荐使用
   # always：每次操作都会备份，安全并且数据完整，但是慢性能差
   appendfsync everysec
   # 重写的时候是否要同步，no可以保证数据安全
   no-appendfsync-on-rewrite no
   # 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时
   # 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
   auto-aof-rewrite-percentage 100
   auto-aof-rewrite-min-size 64mb
   

   RDBまたはAOFを使用する必要がありますか？

   1. キャッシュ損失の期間を受け入れることができる場合は、RDBを使用できます
   2. リアルタイムデータに関心がある場合は、AOFを使用してください