Redis持続化RDB&AOF

4302 ワード

1.なぜ永続化が必要なのか。


Redisの読み書きと応答速度はなぜこんなに速いのか.従来のリレーショナル・データベースとは異なり、Redisのデータベースはすべてリアルタイム・メモリにロードされており、読み書き操作はメモリで直接行うことができ、多くのIO操作を省くことができるため、パフォーマンスが非常に優れています.しかし、メモリに依存するすべてのサービスには、デバイスの障害(ブレークポイントなど)が発生すると、メモリ内のすべてのリアルタイムデータが失われる最大のリブがあります.この問題を解決するために、Redisでは、RDBとAOFの2つの持続的なスキームが提供されています.そのメカニズムは、実際には、メモリ内のデータをファイル形式でディスクにバックアップし、電源オフなどの機械的な障害によるデータ損失の問題を解決するために工夫されています.

2. RDB (Redis DataBase)


実装メカニズム:Redisは単独でサブプロセスを作成して永続化し、データを一時ファイルに書き込み、永続化プロセスが終了した後、最後に永続化されたファイル(dump.rdb)をこの一時ファイルに置き換えます.プロセス全体において、メインプロセスはIO操作を一切行わないので、Redisメインプロセスの持続的な高性能を保証することができる.データを復元すると、再起動するとRedisは作業ディレクトリの下のdumpを自動的にロードする.rdbファイルはメモリにデータを復元する
関連パラメータ:
##     RDB dump   ,                     , dump.rdb  Redis         ,        。           save          RDB  
save  
save 900 1          ## for         
save 300 10          ## for     
save 60 10000              ## for     

##    RDB       ,Redis       ,   yes
stop-writes-on-bgsave-error yes

##   RDB     LZF     dump.rdb      ,  yes
rdbcompression yes

##      dump.rdb      ,  CRC64    ,   RDB   CPU   10%,   
rdbchecksum yes

##        ,   dump.rdb
dbfilename dump.rdb

##   dump.rdb      ,           
dir ./

メリット:
  • 永続化プロセスでもデータ回復プロセスでもRDBの速度は非常に速い
  • ユーザは、永続化の周波数を制御するために手動でパラメータを設定することができ、アプリケーションシーンがより柔軟になる
  • .
  • は大規模でデータの整合性と一貫性に対する要求が低いデータ復旧に適しており、
  • .
    劣勢:
  • RDBの永続化にはforkサブスレッドが必要であり、サブスレッドはcopyメインスレッドのすべてのデータをデバイスのメモリ使用の一時的な2倍に相当し、データ量が特に大きい場合にRDBを使用するとメモリオーバーフローのリスクがある可能性がある
  • 最後に永続化されたデータが失われる可能性があるため、データ整合性に敏感なビジネスでは、RDBによる永続化を推奨しない
  • .
    PLUS:最後に永続化されたデータが失われる可能性があるのはなぜですか.
    RDBはsave条件を設定することによりdumpをトリガし、いずれかのsave条件を満たした後にその条件を書き換える仕組みとなっているが、実際には最後のdumpで修正回数要求に達したものの、時間がまだ到達していないうちにredisプロセスが中止すると、この段階のデータが失われる可能性がある。 例えばsave 300 10という条件では、Redisの300 s内での修正操作回数が10回を超えるため、持続化条件がトリガーされ、システムは300 sが満期になった後にブラシ書きを行うが、満期の数秒前にデバイスが異常にシャットダウンする可能性があり、300 s内で発生したデータ修正情報はすべて失われる

    3. AOF(Append Only File)


    実装メカニズム:RDBの直接書き込み元データとは異なり、AOFはRedisの起動中のすべての書き込み操作を記録し、ログに類似しており、書き込み方式は末尾に追加することしか許されず、変更前に書き込む内容は許されず、デフォルトではappendonlyとして保存されている.aofファイル.データを復元すると、RedisはAOFをメモリにロードし、データの復元を実行します.
    関連パラメータ:
    ##       --      
    appendonly no 
    
    ##    
    appendfilename "appendonly.aof"
    
    ##     
    appendfsync always       ##      ,               ,           
    appendfsync everysec    ##       ,    ,    ,       ,       
    append no        ##        , Redis              

    メリット:
  • のデフォルトのブラシ書き込み周波数は毎秒1回であるため、データの整合性を最大限に保証することができる
  • .
  • AOFは、実行時の書き込みを記録するだけであり、すべてのメインスレッドデータをコピーすることはないため、メモリオーバーフローのリスクは小さい
  • である.
    劣勢:
  • は追加形式の書き込みのみをサポートするため、appendonlyが形成される.aofファイルはますます大きくなり、Rediaのリカバリデータのパフォーマンスに影響します.
  • データの復元には、Redisがappendonlyを実行する必要がある.aof記録の各命令は、回復速度が
  • 遅い
  • 実際の操作命令には、10000個の自己増加1文を1個の自己増加10000文にまとめることができるなど、大きな統合空間があり、AOFはこの点で依然として大きな最適化可能な空間
  • を持っている.
    Rewriteメカニズム:appendonly.aofファイルはますます大きくなる危険性があり、AOFはRewriteメカニズムを設定し、デフォルトはappendonlyである.aofファイルサイズが前回のRewriteに達した後appendonly.aofファイルのサイズが小さい場合、ファイルのサイズが64 Mを超えると、AOFはRewriteを起動し、forkは新しいプロセスを出して一時ファイルを作成し、データベース全体を遍歴し、各key、valueペアをRedisコマンドの形式で一時ファイルに出力します.このプロセスでは、複数のキー値のペアがセットされ、最終ファイルのサイズを小さくするために1つのコマンドで表現されます.rewrite期間中の書き込み操作はメモリのrewrite bufferに保存され、rewriteが成功するとこれらの操作も一時ファイルにappendされ、rewriteが完了するとappendonlyに代わる一時ファイルになる.aofファイル
    ##   Rewrite   -- and -- 
    
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    
    ##          appendfsync  ?    no,      
    no-appendfsync-on-rewrite no

    4.まとめ


    シーンを使用:
  • RDBは、データストリームが大きく、データ回復が速いが、データ整合性に依存しないビジネス、例えばユーザ行動分析などの
  • に適している.
  • AOFは、銀行金融系業務
  • のようなデータ整合性に制限のある業務に適している.
    共存性:AOF機能をデフォルトでオフにするが、実質的にRDBとAOFは共存可能であり、Redisが同時にAOFとRDBの永続化をオンにすると、Redisが再起動するとAOFファイルを優先的に読み取り、データ復旧を行う.AOFはRDBよりもデータ整合性を保証するためである.さらに、Redisデータの復元には、AOFファイルまたはRDBファイルを読み込む必要があるため、これら2つのファイルが破損したり、悪意のある変更を受けたりすることを防止するために、Redisは2つの修復スクリプトを提供し、この2つのファイルを修復する
    ##   AOF  
    redis-check-aof  --fix appendonly.aof
    
    ##   RDB  
    redis-check-dump --fix dump.rdb

    安全性の拡張:実際の生産では、AOFでもRDBでも生成するappendonlyが必要である....rdbファイルをオフサイトでバックアップすることで、単一マシンの完全な破損によるデータのリカバリ不可能な問題を回避できます.