サブスクリプションの公開を実現するためのRedisデータ永続性とRedisの2つの方法

Redisデータ永続化メソッド

Redisはメモリ内データベースです。メモリ内のデータベース状態がディスクに保存されていない場合、サーバープロセスが終了すると、サーバー内のデータベース状態が消え、同時に内部のデータが失われるため、Redisは永続化機能を提供します。

マスタースレーブレプリケーションでは、RDBが（スレーブ上の）バックアップとして使用されます。

Redisには、それぞれRDBとAOFの2つのデータ永続化メソッドがあります。これら2つのメソッドをそれぞれ紹介しましょう。

1. RDBメソッド（Redisデータベース）

1. RDBとは何ですか？

Redisのデータベース状態をメモリにディスクに保存します。RDBファイルは圧縮されたバイナリファイルです。RDBファイルが生成されたときのデータベース状態は、このファイルを介して復元できます（デフォルトでは、dump.rdbファイルに保持され、redisに保存されます）。再起動後、自動的にその中のファイルを読み取ります。1000万の文字列タイプのキーと1GBのスナップショットファイルの場合、メモリと同期する時間は20〜30秒であると報告されています。素人の言葉で言えば、メモリ内のデータセットは、指定された時間間隔内にスナップショットとしてディスクに書き込まれます。これは、用語ではスナップショットと呼ばれます。データが復元されると、スナップショットファイルがメモリに直接読み込まれます。 。

2.RDB永続化プロセスの概要

Redisは、最初に永続化のために子プロセスを作成（フォーク）します。子プロセスはすべてのデータを一時ファイルに書き込みます。この一時ファイルは一時RDBファイルです。このファイルは永続化され、永続化されるまで待機する必要があります。変換プロセスが終了すると、RDB一時ファイルが最後に永続化されたファイルに置き換えられ、公式のRDBファイルも生成されます。プロセス全体を通して、メインスレッドはIO操作を実行しないため、非常に高いパフォーマンスが保証されます。

アプリケーション：
大規模なデータ回復が必要であり、データ回復の整合性がそれほど敏感でない場合、RDB法はAOF法よりも効率的です。ただし、RDBの欠点は、最後の永続性がダウンし、データが失われる可能性があることです。Redisのデフォルトの永続化方法はRDBであり、通常、この構成を変更する必要はありません。

3.構成ファイル内のRDBの構成

rdbによって保存されるファイル名はdump.rdbであり、構成ファイルのスナップショットオプションで構成されます。

構成ファイルでは、スナップショットの永続化頻度のデフォルト設定は次のとおりです。

#设置Redis进行快照镜像的频率
save 900 1         #如果900秒（15分钟）内，至少有一个key进行了修改，我们就进行持久化操作（写入到数据库的持久化文件中）
save 300 10       #如果300秒内（6分钟），有10个key进行了修改，就进行持久化操作
save 60 10000   #如果60秒内（1分钟），有10000个key进行了修改，就进行持久化操作（多线程）

4.RDBトリガーメカニズム

• 構成ファイルの保存ルールが満たされると、rdbルールが自動的にトリガーされてrdbファイルが生成されます。
• フラックスホールコマンドが実行されると、rdbルールもトリガーされてrdbファイルが生成されます。
• Redisを終了すると、rdbファイルも生成されます。

バックアップにより、dump.rdbファイルが自動的に生成されます。

5. rdbファイルを復元する方法は？

• dump.rdbファイルをredis起動ディレクトリに置くだけで、redisはdump.rdbを自動的にチェックして、起動時にデータを復元します。
• このconfig get dirコマンドを使用して起動ディレクトリを表示します。dump.rdbファイルがこのディレクトリにある限り、その中のデータは起動後に自動的に復元されます。
  

6.RDB手動実行コマンドSAVEおよびBGSAVEの導入

• SAVEコマンドは、RDBファイルが作成されるまでRedisサーバープロセスをブロックします。サーバープロセスがブロックされている間、サーバーはコマンド要求を処理できません。
• BGSAVEコマンドは子プロセスをフォークし、子プロセスがRDBファイルの作成を担当し、サーバープロセス（親プロセス）がコマンド要求の処理を続行します。（通常、この方法を使用します）
• RDBファイルの作成が終了する前、つまりデータの永続性が完了する前に、クライアントはSAVEまたはBGSAVEコマンドを再度実行すると、サーバーによって拒否されます。

7.アプリケーションのシナリオと欠点

• 大規模なデータ回復に適しています。
• データの整合性が高くない場合。

実稼働環境では、dump.rdbファイルをバックアップします。

短所：

• 動作には一定の時間間隔がかかります。
• Redisが予期せずダウンした場合、最後に変更されたデータは失われます。
• 子プロセスをフォークする場合、一定量のメモリスペースを占有します。

2. AOF方式（ファイルのみ追加）

すべての書き込みコマンドと履歴を記録し、復元時にこのファイルを1回実行します。

1.AOF法の動作原理

各書き込み操作をログの形式で記録し、Redisが実行したすべての命令を記録します（読み取り操作は記録されません）。ファイルのみを追加でき、ファイルを書き換えることはできません。Redisは起動時にファイルを読み取ります。データの構築、つまりRedisの再起動後、ログファイルの内容に応じて書き込みコマンドを前後に実行し、データ復旧作業を完了します。

デフォルトのAOF方式では、ファイルを無制限に追加します。これにより、ファイルがどんどん大きくなります。

2.AOF永続化プロセス

まず、親プロセスが子プロセスをフォークするために戻り、次に子プロセスがメモリ内のデータスナップショットに従ってデータをAOF一時ファイルに再書き込みし、次に親プロセスが書き込みコマンドをキャッシュして書き込みコマンドを書き込みます。元のAOFファイルに対して、子プロセスが書き込みを終了すると、親プロセスに通知します。通知を受信した後、親プロセスはキャッシュ内の書き込みコマンドをAOF一時ファイルに書き込み、親プロセスは一時ファイルを元のファイルに置き換えます。 AOFファイルの名前が変更されて永続化操作が完了し、最後に書き込みコマンドが後で表示された場合は、新しいAOFファイルに追加されます。

3.構成ファイル内のAOFの構成

AOFによって保存されるファイル名はappendonly.aofで、このメソッドはデフォルトでは有効になっていません。AOFを使用する必要がある場合は、構成ファイルで手動で有効にする必要があります。構成の詳細は次のとおりです。

#开启aof模式的配置，默认是不开启，因为Redis默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用了。
appendonly no

#aof持久化的文件名字
appendfilename "appendonly.aof"

#配置持久化同步sync的选项（持久化策略），默认是everysec每秒同步一次
# appendfsync always     #  每次修改都会同步sync ，这种方式比较耗性能
appendfsync everysec    #  每一秒执行一次同步sync，可能会丢失这1s的数据。
# appendfsync no           #  不执行同步sync，这个时候操作系统自己同步数据，速度最快。
#是否进行重写选项。在 aof 重写或者写入 rdb 文件的时候，会执行大量 IO，此时对于 everysec 和 always 的 aof 模式来说，执行同步(fsync) 会造成阻塞过长时间，no-appendfsync-on-rewrite 字段设置为默认设置为 no。如果对延迟要求很高的应用，这个字段可以设置为 yes，否则还是设置为 no，这样对持久化特性来说这是更安全的选择。设置为 yes 表示 rewrite 期间对新写操作不同步fsync,暂时存在内存中,等 rewrite 完成后再写入。
#默认为 no，建议 no，可以保证数据的安全性。Linux 的默认 fsync 策略是 30 秒。可能丢失 30 秒数据。
no-appendfsync-on-rewrite no

#aof文件的自动重写配置。当目前的aof文件大小超过上一次重写的aof文件大小的百分之多少的时候进行重写，当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志进行重写。默认设置为100，设为100意思就是当前aof文件大小是上次日志重写的aof文件大小的两倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

#允许重写最小aof文件的大小设置，如果超过了64MB就会去写一些其它的文件。
auto-aof-rewrite-min-size 64mb

#指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，设置为yes会log并继续，设置为no会直接恢复失败
aof-load-truncated yes

#加载redis时，可以识别AOF文件以“redis”开头。
#字符串并加载带前缀的RDB文件，然后继续加载AOF尾巴
aof-use-rdb-preamble yes

AOFモードはデフォルトでは有効になっていません。手動で構成する必要があります。appendonly no中央noを変更しyesてAOFモードを有効にしてから、Redisを再起動して有効にします。

4. appendonly.aofファイルに問題がある場合、破損または破損している場合はどうなりますか？

appendonly.aofファイルが破損している場合、Redisに接続すると、次のエラー（接続が拒否されました）が報告されます。

これは、appendonly.aofファイルに問題があり、Redisを開始できないため、このaofファイルを修復する必要があるためです。Redisは、appendonly.aofファイルを修復できるredis-check-aofツールを提供します。ファイルはbinディレクトリにあります。
コマンド：redis-check-aof --fix appendonly.aof

このコマンドを実行すると、AOFファイルが正常に修復されたことがわかります。再接続するだけです。

5.長所と短所

（1）利点：

• すべての変更が同期されるため、ファイルの整合性が向上します。
• 1秒に1回同期すると、1秒のデータが失われる可能性があります。
• 同期しない、最高の効率。

（2）デメリット：

• データファイルと比較すると、AOFはRDBよりもはるかに大きく、修復速度もRDBよりも遅くなります。
• AOFはRDBよりも実行が遅いため、Redisのデフォルト構成はRDBです。

展開

1. RDB永続化メソッドは、指定された時間間隔内にデータのスナップショットストレージを実行できます。

2. AOF永続化メソッドは、サーバーへの各書き込み操作を記録します。サーバーが再起動すると、これらのコマンドが再実行されて元のデータが復元されます。AOFコマンドは、Redisプロトコルを使用して、各書き込み操作をファイルの最後に追加して保存します。RedisはAOFファイルのボリュームが大きくなりすぎないように、バックグラウンドでAOFファイルを書き換えます。

3.キャッシュのみ。サーバーの実行中にのみデータを存在させたい場合は、永続性を使用する必要はありません。

4.2つの永続化メソッドを同時に開きます

• この場合、Redisを再起動すると、最初にAOFファイルをロードして元のデータを復元します。これは、通常の状況では、AOFファイルによって保存されたデータセットはRDBファイルによって保存されたデータセットよりも完全であるためです。

• RDBデータはリアルタイムではなく、サーバーは、両方を同時に使用しているときにサーバーが再起動したときにのみAOFファイルを見つけます。AOFだけを使用する必要がありますか？RDBはデータベースのバックアップ（AOFは絶えず変化する場合のバックアップには適していません）、高速再起動、および潜在的なAOFバグがないため、ここではお勧めしません。予防措置としてRDBを保管してください。

5.パフォーマンスの推奨事項

• RDBファイルはバックアップ目的でのみ使用されるため、RDBファイルをスレーブ（スレーブ）に永続化することをお勧めします。15分のバックアップのみで十分です。保存9001のみがルールです。

• AOFが有効になっている場合、最悪の場合、2秒以内のデータのみが失われるという利点があります。起動スクリプトは簡単です。独自のAOFファイルをロードするだけです。コストは、継続的なIOをもたらし、もう1つはAOFリライトの終了時に、リライトプロセス中に生成された新しいデータを新しいファイルに書き込むことは避けられません。ブロッキングの機会は避けられません。ハードディスクが許す限り、AOFリライトの頻度を可能な限り減らす必要があります。AOFリライトのデフォルト値である64Mは小さすぎます。 5G以上に設定でき、デフォルト値はメタサイズの100％を超え、適切な値に書き換えることができます。

• AOFを有効にしない場合、高可用性を実現するためにマスタースレーブの複製にのみ頼ることができます。これにより、多くのIOを節約し、再試行によって引き起こされるシステムの変動を減らすことができます。コストは、マスター/スレーブが同時にドロップされた場合（電源障害）です。 、10分以上のデータが失われます。起動スクリプトは、2つのマスター/スレーブのどちらのRDBファイルが更新されたかを比較し、新しいファイルをロードします。Weiboはこのアーキテクチャです。

Redisの公開とサブスクライブ

Redisの発行とサブスクライブ（pub / sub）は、メッセージ通信モードです。送信者（pub）がメッセージを送信し、サブスクライバー（sub）がメッセージを受信します。Redisクライアントは、任意の数のチャネルにサブスクライブできます。

WeChat、Weibo、フォローシステムなど。

購読/公開モデル

メッセージ発行者は最初にメッセージをチャネル（Redisサーバー）に発行し、次にチャネルはメッセージをサブスクライバーに発行します。チャネルにサブスクライブするユーザー（メッセージサブスクライバー）がチャネルから送信されたメッセージを受信する限り、そうでない場合はこのチャンネルに登録している場合、メッセージを受信することはできません。

例：たとえば、WeChatの公式アカウントで記事をプッシュすると、作成者が記事を作成すると、その記事が公式アカウントに公開され、公式アカウントをフォローしているユーザーは、公式アカウントから送信された情報を受け取ります。 。

プロセス全体で、作成者は図のニュース発行者に相当し、公式アカウントはチャネルに相当し、公式アカウント（チャネル）をフォローしているユーザーがメッセージサブスクライバーになります。

サブスクリプション関係の紹介

1.次の図は、チャネルchannel1と、このチャネルにサブスクライブする3つのクライアント（client2、client5、client1）間の関係を示しています。

2.PUBLISHコマンドを介して新しいメッセージがチャネルchannel1に送信されると、メッセージは、それにサブスクライブしている3つのクライアントに送信されます。

3.関連コマンドの概要

（1）PSUBSCRIBE pattern [pattern .....]：特定のモードに準拠する1つ以上のチャネルをサブスクライブします。

（2）PUBSUB subcommand [argument [argument ....]]：サブスクリプションおよび公開システムのステータスを表示します。

（3）PUBLISH channel message：指定したチャネルチャネルに情報メッセージを送信します。

（4）PUNSUBSCRIBE [pattern [pattern ....]]：特定のモードのすべてのチャネルのサブスクライブを解除します。

（5）SUBSCRIBE channel [channel ....]：特定の1つ以上のチャネルの情報をサブスクライブします。

（6）UNSUBSCRIBE [channel [channel ....]]：指定されたチャネルからの退会を指します

上記のコマンドは、オンラインチャットルーム（チャットルーム）やリアルタイムブロードキャスト、リアルタイムリマインダーなどのインスタントメッセージングアプリケーションを構築するために広く使用されています。

4.テスト：

まず、2つのクライアントを準備します。1つはメッセージ発行者（pub）の役割用で、もう1つはメッセージサブスクライバー（sub）の役割用です。

（1）サブスクライバーはjavaチャネルをサブスクライブします：

（2）パブリッシャーはjavaチャネルでメッセージを公開します：

（3）サブスクライバーはJavaチャネルからメッセージを受信します：

5.原則：

• RedisはCで実装されています。Redisソースコードのpubsub.cファイルを分析することにより、公開およびサブスクライブメカニズムの基本的な実装を理解できます。

• Redisは、publish、subscribe、psubsctibeなどのコマンドを介してpublishおよびsubscribe機能を実装します。

• sunsctibeコマンドを使用してチャネルにサブスクライブした後、redis-serverにディクショナリが保持されます。ディクショナリのキーはチャネルであり、ディクショナリの値はリンクリストです。リンクリストには、このチャネルにサブスクライブするすべてのクライアントが格納されます。subscribeコマンドの鍵は、特定のチャネルのサブスクリプションリストにクライアントを追加することです。

• 公開コマンドを使用してサブスクライバーにメッセージを送信します。redis-serverは指定されたチャネルをキーとして使用し、このチャネルにサブスクライブしているすべてのクライアントを維持しているチャネル辞書で記録するリンクリストを検索し、このリンクリストをトラバースして、メッセージをすべてのサブスクライバー。

• Pub / Subは、文字通り公開とサブスクライブを意味します。Redisでは、メッセージの公開とメッセージのサブスクリプションにキー値を設定できます。メッセージがキー値で公開されると、すべてそれを購読するクライアントは、対応するメッセージを受け取ります。この機能の最も明白な使用法は、通常のインスタントチャット、グループチャット、その他の機能などのリアルタイムメッセージングシステムとして使用することです。

6.使用シナリオ

• リアルタイムメッセージングシステム。
• リアルタイムチャット（チャンネルはチャットルームとして使用され、情報は全員に返されます）。
• 購読するか、システムをフォローすることができます。

もう少し複雑なシナリオでは、メッセージミドルウェアMQを使用します。

作成するのは簡単ではありません。この記事が役に立ったら、私にいいねをしてサポートしてください。