redisデータ持続化

3867 ワード

RedisはRDBとAOFの2つの永続化メカニズムをサポートし、永続化機能はプロセスの終了によるデータ損失の問題を効果的に回避し、次回の再起動時に以前の永続化されたファイルを利用してデータ回復を実現することができる.RDB永続化RDB永続化は、現在のプロセスデータ生成スナップショットをハードディスクに保存するプロセスであり、RDB永続化プロセスを手動トリガと自動トリガに分ける.データ永続化の手動トリガ

手動トリガはsaveとbgsaveにそれぞれ対応します。 save命令:RDBプロセスが完了するまで、現在のredisサーバをブロックします(オンラインでは使用が推奨されず、ブロック時間が長すぎます)。 bgsave命令:redisプロセスはfork操作を実行してサブプロセスを作成し、RDB持続化プロセスはサブプロセスが責任を負い、完了後に自動的に終了する(ブロックはfork遮断でのみ発生する)。bgsave命令を手動で実行すると、Redis親プロセスは、RDB/OFサブプロセスのような現在実行中のサブプロセスが存在するかどうかを判断し、bgsaveコマンドが存在する場合は直接戻る。ない場合はforkがサブプロセスを出て、fork操作中に親プロセスがブロックされ、info statコマンドでlatest_を表示できます。fork_usercオプションでは、マイクロ秒単位で最近のfork操作にかかる時間を取得できます。親プロセスforkが完了すると、bgsaveコマンドは「Background saving started」情報を返し、親プロセスをブロックすることなく、他のコマンドに応答し続けることができます。サブプロセスはRDBファイルを作成し、親プロセスメモリに基づいて一時スナップショットファイルを生成し、完了すると元のファイルを原子置換します。lastsaveコマンドを実行すると、info統計のrdb_に対応する最後にRDBが生成された時間を取得できます。last_save_timeオプション。プロセスは親プロセスに完了を示す信号を送信し、親プロセスは統計を更新します。

例は次のとおりです.

127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> 
#                             ：
dbfilename dump.rdb    #            
dir /usr/local/redis/data    #               
[root@redis data]# ll /usr/local/redis/data   #     dump.rdb      
    28
-rw-r--r-- 1 root root   725 3    9 14:15 dump.rdb

redisが起動するたびに、指定されたディレクトリの下でdumpを探します.rdbファイルを読み取り、その中のデータをredisに読み込むことが、データの持続化を可能にする根本的な原因です.データ永続化の自動トリガ

4つの自動トリガの場合: プロファイルでm秒以内にデータが何回変化するかを定義し、bgsaveを自動的にトリガーします。ノードからフルコピー操作を実行すると、プライマリノードはbgsaveを自動的に実行し、RDBを形成するファイルは他のノードに送信される。 debug reloadコマンドを実行してredisを再ロードすると、save操作も自動的にトリガーされます。 shutdownを実行する場合、AOF永続化がオンになっていない場合、bgsaveが自動的に実行されます。

プロファイルのRDBに関連する構成は次のとおりです.

#             ，         ，          。
#                   
save 900 1   #  900 （15  ）   1 key    ，   
save 300 10    #  300 （5  ）   10 key    ，   
save 60 10000   #  60 （1  ）   10000 key    ，   
dbfilename dump.rdb    #       
dir /usr/local/redis/data    #

次のデフォルト値はyesであり、RDBが有効になり、最後のバックグラウンドでデータの保存に失敗した場合、Redisはデータの受信を停止するかどうか.これにより、データがディスクに正しく永続化されていないことを認識できます.そうしないと、災害の発生に気づかないことになります.redisが再起動されると、データの受信を再開することができます.

stop-writes-on-bgsave-error yes  
#    yes  ， redis               ，redis           。

次のオプションのデフォルト値はyesで、ディスクに格納されているスナップショットデータに対して圧縮ストレージを行うかどうかを示します.

rdbcompression yes

次のオプションのデフォルト値はyesです.スナップショットを格納した後、redisにCRC 64アルゴリズムを使用してデータ検証を行うこともできますが、パフォーマンスの消費量は約10%増加します.パフォーマンスの最大化を望む場合は、この機能をオフにします.

rdbchecksum yes

AOFデータ持続化に関するパラメータは以下の通りである.

appendonly no   #     aof     ，     yes    aof

デフォルトredisではrdb方式の持続化が用いられており、この方式は多くのアプリケーションで十分である.しかし、redisが途中でダウンタイムすると、数分のデータ損失を招く可能性があります.saveに基づいてポリシーを永続化し、Append Only Fileは別の永続化方式であり、より良い永続化特性を提供することができます.Redisは書き込みのたびに受信後にappendonlyに書き込む.aofファイルは、起動するたびにRedisがこのファイルのデータをメモリに読み込み、RDBファイルを無視します.

appendfilename "appendonly.aof"   # aof   
# appendfsync always
appendfsync everysec
# appendfsync no

上の3行はaof方式の持続化戦略です。 Always:書き込みのたびにfsyncを実行し、データがディスクに同期することを保証しますが、パフォーマンスに影響します。オンラインでは推奨されません。 everysec:毎秒順次fsync操作を実行することを示します。つまり、ダウンタイムが発生すると最大1秒のデータが失われ、データにそれほど敏感でない場合は、この方法を推奨します。 No:fsyncを実行しないことを示し、オペレーティングシステムによってデータがディスクに同期することを保証し、速度が最も速い。しかし、最長の同期サイクルは30 sある可能性があるため、オンラインでは推奨されません。

auto-aof-rewrite-percentage 100

aof自動書き換え構成は、現在のaofファイルサイズが前回書き換えたaofファイルサイズの何パーセントを超えて書き換えられているか、すなわちaofファイルが一定のサイズに増加した場合、Redisはbgrewriteaofを呼び出してログファイルを書き換えることができる.現在のAOFファイルサイズが前回のログ書き換えでAOFファイルサイズの2倍(100に設定)になった場合、自動的に新しいログ書き換えプロセスが開始されます.

auto-aof-rewrite-min-size 64mb

書き換えを許可する最小aofファイルサイズを設定し、所定のパーセントに達してもサイズが小さい場合に書き換えることを回避します.デフォルトは64 Mです.生産では実際の状況に応じて、いくつかのGに指定される場合があります.

redisトークンメカニズムを用いて電子商取引の秒殺を実現する

Asp.Netは支付宝のモバイル端末のホームページの支払いを開通します