Redis の永続性、パブリッシュとサブスクライブ、クラスターの詳細

仮説

前に述べたように、Redis には Memcache などの他のキャッシュ製品に比べて明らかな利点があります。つまり、Redis は単純なキー値型データをサポートするだけでなく、 list、set、zset、hash などのデータ構造のストレージも提供します。これらの豊富なデータ型により、Redis のもう 1 つの大きな利点である永続性を紹介します。

Rediisはインメモリデータベースなので、データベースの内容をメモリ上に保存する、いわゆるインメモリデータベースですが、MysqlやOracleなどの従来のリレーショナルデータベースがハードディスクに直接内容を保存するのに比べ、インメモリ データベースの読み取りおよび書き込み効率は従来のデータベースよりも低く、はるかに高速です (メモリの読み取りおよび書き込み効率は、ハードディスクの読み取りおよび書き込み効率よりもはるかに優れています)。
ただし、メモリへの保存にはデメリットもあり、電源が切れたりダウンしたりすると、メモリデータベース内のデータがすべて失われます。
この欠点を解決するために、Redis はメモリ内のハードディスクにデータを永続化し、永続ファイルでデータベースを復元する機能を提供します。Redis は 2 つの形式の永続性をサポートしています。1 つは RDB スナップショット、もう 1 つは AOF データベース ストレージです。

NoSQLの保存方法

RDBスナップショット(redis DateBase)

概要
EDB は Redis が永続化のために使用する方式で、現在のメモリ内のデータセットのスナップショット、つまり Snapshot スナップショット (データベース内のすべてのキーと値のペアのデータ) をディスクに書き込みます。復元時には、スナップショット ファイルがメモリに直接読み込まれます。

トリガーメソッド

Redis 構成ファイルを表示する

################################ 快照 #################################
#
# 保存数据到磁盘，格式如下:
#
# save <seconds> <changes>
#
# 指出在多长时间内，有多少次更新操作，就将数据同步到数据文件rdb。
# 相当于条件触发抓取快照，这个可以多个条件配合
#
# 比如默认配置文件中的设置，就设置了三个条件
#
# save 900 1 900秒内至少有1个key被改变
# save 300 10 300秒内至少有10个key被改变
# save 60 10000 60秒内至少有10000个key被改变
save 900 1
save 300 10
save 60 10000
# 存储至本地数据库时（持久化到rdb文件）是否压缩数据，默认为yes
rdbcompression yes
# 本地持久化数据库文件名，默认值为dump.rdb
dbfilename dump.rdb
# 工作目录
#
# 数据库镜像备份的文件放置的路径。
# 这里的路径跟文件名要分开配置是因为redis在进行备份时，先会将当前数据库的状态写入到一个临时文件中，
等备份完成时，
# 再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路
径当中。
#
# AOF文件也会存放在这个目录下面
#
# 注意这里必须制定一个目录而不是文件
dir ./

save: これは、Redis をトリガーする RDB 永続条件、つまりメモリ内のデータをいつハードディスクに保存するかを構成するために使用されます。たとえば、
「mn を保存」などです。データセットが m 秒以内に n 回変更されたときに bgsave が自動的にトリガーされることを示します (このコマンドは、RDB 永続化コマンドを手動でトリガーするために以下で紹介されます
)。
rdbcompression: デフォルト値はyesです。ディスク上に保存されるスナップショットについて、圧縮保存を行うかどうかを設定できます。その場合、
redis は圧縮に LZF アルゴリズムを使用します。圧縮に CPU を消費したくない場合は、この機能をオフに設定できますが、
ディスクに保存されるスナップショットは比較的大きくなります。
stop-writes-on-bgsave-error : デフォルト値は Yes です。RDB が有効で最後のバックグラウンド データの保存が失敗したときに、 Redis が
データの受信を停止するかどうか。これにより、データがディスクに適切に保存されていないことがユーザーに認識されます。そうしないと、障害が発生したことに誰も気付かなくなります
。Redis が再起動すると、データの受信が再び開始される可能性があります。
rdbchecksum: デフォルト値はyesです。スナップショットを保存した後、Redis に CRC64 アルゴリズムを使用させてデータ検証を行うこともできますが、
これによりパフォーマンスの消費が約 10% 増加します。パフォーマンスを最大限に向上させたい場合は、この機能をオフにすることができます。
dbfilename: スナップショットのファイル名を設定します。デフォルトは dump.rdb です。
dir: スナップショット ファイルのストレージ パスを設定します。この構成項目はファイル名ではなくディレクトリである必要があります。デフォルトでは、
現在の構成ファイルと同じディレクトリに保存されます。

トリガーを自動的にテストする

1 データテストの追加、データベースファイルの検索
2 ファイル名の変更
3 スナップショットパスの表示

手動トリガー

RDB 永続化のために Redis を手動でトリガーするには 2 つのコマンドがあります:
save: このコマンドは現在の Redis サーバーをブロックします。save コマンドの実行中、RDB プロセスが完了するまで Redis は他のコマンドを処理できません
。明らかに、このコマンドは比較的大きなメモリを持つインスタンスに対して長期的なブロックを引き起こしますが、これは致命的な欠陥ですが、この問題を解決するために、redis は 2 番目の方法を提供します
。(非推奨)
bgsave: このコマンドを実行すると、Redis はバックグラウンドでスナップショット操作を非同期に実行し、スナップショットはクライアントの要求に応答することもできます。具体的な操作としては、
Redis プロセスが fork 操作を実行して子プロセスを作成し、RDB 永続化プロセスは子プロセスの責任となり、完了後に自動的に終了します。ブロッキングは
子プロセスを作成するフォーク段階でのみ発生し、通常の時間は非常に短いです。
基本的に、Redis 内のすべての RDB 操作は bgsave コマンドを使用します。
RDB 永続化をトリガーできる特別な操作も 2 つありますが、特殊な状況のため、これらは手動トリガー条件としては使用されません。

flashall.flushdb コマンドを実行すると dump.rdb ファイルも生成されますが、これは空で意味がありません。

Redis サービスを閉じると、ルールが bgsave を使用してデータを保存します。

RDBデータリカバリ（企業管理者がよく使用する方法）

バックアップ ファイル (dump.rdb) を redis インストール ディレクトリに移動してサービスを開始するだけで、redis はファイル データをメモリに自動的にロードします。
RDB ファイルのロード中は、ロード作業が完了するまで Redis サーバーがブロックされます。
サーバーが起動される現在のディレクトリは redis-*** である必要があります。そうしないと、スナップショットによって生成されたパスでエラーが発生します。

127.0.0.1:6379> config get dir
dir
/opt/redis-7.0.4

テストファイルの回復

RDB 永続化を停止する

場合によっては、Redis の永続化機能ではなく、Redis のキャッシュ機能のみを使用したい場合があるため、この時点では RDB 永続化を停止した方がよいでしょう。上で説明したように、設定ファイル redis.conf で、すべての保存行をコメントアウトして保存機能を無効にするか、空
の文字列を直接指定して無効にすることができます: save ""

# save 60 10000
save ""

コマンドを実行することもできます

redis-cli config set save ""

RDB の長所と短所 (一か八かの面接の質問)

アドバンテージ

1. RDB は、特定の時点での Redis のデータセットを保存する非常にコンパクトなファイル (デフォルトで圧縮) です。
   このようなファイルは、バックアップや災害復旧に最適です。
2. RDB ファイルを生成するとき、redis メイン プロセスはすべての保存作業を処理するために子プロセスを fork() します。メイン プロセスはディスク
   IO 操作を実行する必要はありません。
3. RDB は、AOF よりも高速に大規模なデータセットを復元します。
   不利益
4. RDB データのリアルタイム永続性/第 2 レベルの永続性を実現する方法はありません。bgsave は実行のたびに子プロセスを作成するための fork 操作を行う必要があるため
   、負荷の高い操作 (メモリ上のデータが複製され、約 2 倍の拡張を考慮する必要がある) となり、頻繁に実行するコストが高くなります。高すぎる（パフォーマンスに影響する
   ）
5. RDB ファイルは特定のバイナリ形式で保存されます。Redis のバージョンが進化する過程で、複数の形式の RDB バージョンが存在します。
   古いバージョンの Redis サービスは新しいバージョンの RDB 形式と互換性がないという問題があります (バージョンの非互換性）
6. 一定の間隔でバックアップを作成します。これにより、redis が予期せずダウンした場合、最後のスナップショット以降のすべての変更が失われます (データが
   失われます)。

RDB自動貯蓄の原理（給料の高低差質問）

Redis にはサーバー状態構造があります。

struct redisService{
    
    
//1、记录保存save条件的数组
struct saveparam *saveparams;
//2、修改计数器
long long dirty;
//3、上一次执行保存的时间
time_t lastsave;
}

まず、保存条件を記録する saveparam 配列を確認します。その中の各要素は saveparams 構造体です。

struct saveparam{
    
    
//秒数
time_t seconds;
//修改数
int changes;
};

先ほど、 redis.conf 構成ファイルに保存を構成しました。

save 3600 1 ：表示3600 秒内如果至少有 1 个 key 的值变化，则保存
save 300 100：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

サーバー状態の saveparam 配列は次のようになります。

ダーティ カウンタと lastsave 属性 ダーティ
カウンタは、save コマンドが最後に正常に実行されてから Redis サーバーが変更された回数 (書き込み、削除、更新を
含むなど）。
lastsave 属性は、save コマンドまたは bgsave コマンドが最後に正常に実行された時刻を記録するタイムスタンプです。

実行原理: これら 2 つの属性により、サーバーが変更操作を正常に実行すると、ダーティ カウンタが 1 ずつ増加し、lastsave 属性により、最後に保存または bgsave が実行された時間が記録されます。Redis サーバーには定期操作機能もあります。severCron、デフォルトは 100 ミリ秒ごとに実行されます
。この関数は、saveparams 配列内のすべての保存条件を調べてチェックします。1 つの条件が満たされる限り、
bgsave コマンドが実行されます。
実行が完了すると、ダーティ カウンタは 0 に更新され、lastsave もコマンド実行の完了時刻に更新されます。

AOF

概要

Redis の永続化メソッドの 1 つである RDB は、キーと値のペアをデータベースに保存することによってデータベースの状態を記録します。もう 1 つの永続化方法である AOF は
、Redis サーバーによって実行された書き込みコマンドを保存することでデータベースの状態を記録します。AOF は、データベースの状態を記録するという目的を
達成するために、データベースに書き込むすべてのコマンド (およびそのパラメーター) をプロトコル テキストの形式で AOF ファイルに記録します。各操作はログ形式で記録され、redis によって実行されたすべての命令が記録されます (読み取り操作は記録されません)、ファイルの追加のみが可能で書き込みはできません。、データファイルの復元が完了しました

たとえば、次のコマンドの場合: RDB 永続化メソッドは、3 つのキーと値のペア str1、str2、および str3 を RDB ファイルに保存します。一方、AOF 永続化メソッドは、実行されたset、sadd、および lpush コマンドを RDB ファイルに

保存します。
AOF ファイル。

AOF構成

############################## AOF ###############################
# 默认情况下，redis会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频
繁，
#如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失。
# 所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。
# 开启append only模式之后，redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中，
#当redis重新启动时，会从该文件恢复出之前的状态。
# 但是这样会造成appendonly.aof文件过大，所以redis还支持了BGREWRITEAOF指令，对appendonly.aof
进行重新整理。
# 你可以同时开启asynchronous dumps 和 AOF
appendonly no
# AOF文件名称 (默认: "appendonly.aof")
# appendfilename appendonly.aof
# Redis支持三种同步AOF文件的策略:
#
# no: 不进行同步，系统去操作 . Faster.
# always: always表示每次有写操作都进行同步. Slow, Safest.
# everysec: 表示对写操作进行累积，每秒同步一次. Compromise.
#
# 默认是"everysec"，按照速度和安全折中这是最好的。
# 如果想让Redis能更高效的运行，你也可以设置为"no"，让操作系统决定什么时候去执行
# 或者相反想让数据更安全你也可以设置为"always"
#
# 如果不确定就用 "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
# AOF策略设置为always或者everysec时，后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作
# 在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复，即使fsync在另外一个线程进行处理
#
# 为了减缓这个问题，可以设置下面这个参数no-appendfsync-on-rewrite
#
# This means that while another child is saving the durability of Redis is
# the same as "appendfsync none", that in pratical terms means that it is
# possible to lost up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no
# Automatic rewrite of the append only file.
# AOF 自动重写
# 当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写
#
# 它是这样工作的：Redis会记住上次进行些日志后文件的大小(如果从开机以来还没进行过重写，那日子大小在开
机的时候确定)
#
# 基础大小会同现在的大小进行比较。如果现在的大小比基础大小大制定的百分比，重写功能将启动
# 同时需要指定一个最小大小用于AOF重写，这个用于阻止即使文件很小但是增长幅度很大也去重写AOF文件的情况
# 设置 percentage 为0就关闭这个特性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendonly: デフォルト値は no です。これは、redis がデフォルトで永続化に rdb メソッドを使用することを意味します。AOF 永続化メソッドを有効にしたい場合は、
appendonly を yes に変更する必要があります。
appendfilename: aof ファイル名、デフォルトは「appendonly.aof」です。
appendfsync**: **aof 永続化戦略の構成。

1. no は fsync が実行されないことを意味し、オペレーティング システムはデータがディスクに同期されることを保証します。これは最も高速ですが、あまり安全ではありません。
2. always は、データがディスクに確実に同期されるようにデータが書き込まれるたびに fsync が実行されることを意味しますが、これは非常に非効率です。
3. 3. Everysec は、fsync が 1 秒ごとに実行されることを意味し、この 1 秒のデータが失われる可能性があります。通常は、セキュリティと効率を考慮して、everysec を選択します
      。(デフォルト)
      no-appendfsync-on-rewrite: aof が aof ファイルを書き換えたり書き込んだりすると、大量の IO が実行されます。このとき、everysec および
      always の aof モードでは、fsync を実行すると長時間のブロッキングが発生します。 no -appendfsync-on-rewrite フィールドは
      デフォルトで no に設定されます。高いレイテンシ要件があるアプリケーションの場合、このフィールドは [はい] に設定できますが、それ以外の場合は [いいえ] に設定されたままになります。これは
      永続性機能にとってより安全な選択です。これが「yes」に設定されている場合、新しい書き込み操作は書き換え中に fsync されず、一時的にメモリーに保管され、書き換えが完了した後に書き込まれることを意味します。デフォルトは「no」で、「yes」が推奨されます
      。 。Linux のデフォルトの fsync ポリシーは 30 秒です。30 秒間のデータが失われる可能性があります。デフォルト値は「いいえ」です。
      auto-aof-rewrite-percentage: デフォルト値は 100 です。Aof は構成を自動的に書き換えます。現在の aof ファイル サイズが最後に書き換えられた
      aof ファイル サイズを超えると、書き換えられます。つまり、aof ファイルが特定のサイズに達すると、Redis は bgrewriteaof を呼び出して
      ログ 現在の AOF ファイル サイズが、前回のログ書き換えで取得した AOF ファイルのサイズ (100 に設定) の 2 倍になると、新しい
      ログ書き換えプロセスが自動的に開始されます。64M - 40M - 80M(55M) - 110M(70M)
      自動 aof-rewrite-min-size: 64mb。再書き込みが許可される aof ファイルの最小サイズを設定し、
      合意されたパーセンテージに達してもサイズがまだ小さい場合の再書き込みを回避します。
      aof-load-truncated: aof ファイルは最後に不完全である可能性があります。redis が起動すると、aof ファイルのデータがメモリにロードされます。
      Redis が配置されているホスト オペレーティング システムがダウンした後に再起動が発生する場合があります。Redis のダウンタイムや異常終了によって末尾が不完全になることはありません。Redis を終了させるか、可能な限り多くのデータをインポートするかを選択できます
      。「はい」を選択すると、切り詰められた aof ファイルがインポートされるときに
      、ログが自動的にクライアントに公開されてからロードされます。「いいえ」の場合、ユーザーは redis-check-aof を使用して AOF ファイルを手動で修復する必要があります
      。デフォルト値は「はい」です。

AOFを有効にする

デフォルトでは有効になっていません。手動で有効にする必要があります。AOF と RDB は同時に有効になっており、AOF 戦略の
appendonly yes がデフォルトで使用されます

。構成が完了した後、redis が再起動され、いくつかの値が使用されることに注意してください。 # vim View aof file
#7.04 バージョン aof ファイルの保存先が appendonlydir フォルダーに変更されました 次に、 appendonly.aof.1.incr.aof を検索して、

すべての書き込み操作をログの形式で記録します。このファイルが破損している場合は、次の
コマンドで復元できます。

AOFファイル障害の修復

# 关闭redis
# 删除dump.rdb
# 随便修改点aof文件
# 重新启动redis

redis-check-aof --fix ツールを使用してファイルを修復し、

修復後に再起動します。

AOFファイル書き換えメカニズム

AOF ファイルには、基本ファイル、増分ファイル、マニフェスト ファイルの 3 種類のファイルが含まれます。基本ファイルは通常、rdb 形式であり、
rdb によって永続化されるデータ ファイルです。
AOF の永続性とは、Redis が書き込みコマンドを AOF ファイルに継続的に記録することを意味するため、Redis が継続するにつれて、AOF ファイルはますます大きくなり、ファイルが大きくなるほど、サーバーのメモリも大きくなり、AOF の回復に必要な時間も長くなります
。この問題を解決するために、Redis は書き換えメカニズムを追加しました
。AOF ファイルのサイズが設定されたしきい値を超えると、Redis は AOF ファイルのコンテンツ圧縮を開始し、
データを復元できる最小限の命令セットのみを保持します。コマンド bgrewriteaof を使用して書き換えることができます。

たとえば、次のコマンドの場合:

AOF ファイルが書き換えられない場合、AOF ファイルには 4 つの SADD コマンドが保存されます。AOF が書き換えに使用される場合、次の
コマンドのみが AOF ファイルに保持されます
。 「犬」「虎」「パンダ」「ライオン」「猫」は、
AOF ファイルの再書き込みでは、元のファイルを再編成するのではなく、サーバーの既存のキーと値のペアを直接読み取り、コマンドを使用して以前のキーと値のペアを置き換えることを意味します
。記録されたキーと値のペア。元の AOF ファイルを置き換える新しいファイルを生成するコマンド。

AOF 書き換えトリガー メカニズム:

redis.conf 構成ファイルの auto-aof-rewrite-percentage を通じて、デフォルト値は 100、auto-aof-rewrite-minsize: 64mb 構成、つまり、デフォルトで Redis は AOF サイズを記録します。最後の書き換え、デフォルト AOF ファイルのサイズが
最後の書き換え後のサイズの 2 倍になり、ファイルが 64M より大きい場合、この構成がトリガーされます。
ここでも、Redis はシングルスレッド ジョブであることがわかりますが、AOF の書き換えに長時間かかると、AOF の書き換え中、Redis は長時間他のコマンドを処理できなくなり、明らかに耐えられません
。Redis でこの問題を解決するための解決策は、AOF 書き換え
プログラムをサブルーチンに入れることです。これには 2 つの利点があります。

1. 子プロセスによる AOF 書き換え中、サーバー プロセス (親プロセス) は他のコマンドの処理を続行できます。
2. 子プロセスには親プロセスのデータのコピーがあり、スレッドの代わりに子プロセスを使用すると、ロックの使用を回避しながらデータのセキュリティを確保できます
   。
   サブプロセスを使用すると上記の問題は解決されますが、新しい問題も発生します。サブプロセスが AOF 書き換えを実行しているため、サーバー プロセスはまだ
   他のコマンドを処理しており、この新しいコマンドによってデータベースも変更される可能性があり、データベースの現在の状態は次のようになります。書き換えられた AOF ファイルの状態と一致しません
   。
   このデータ状態の不一致の問題を解決するために、Redis サーバーは子
   プロセスの作成 Redis サーバーが書き込みコマンドを実行するときに、AOF リライト バッファーにも書き込みコマンドを送信します。バッファ。子プロセスは
   AOF 書き換えが完了すると親プロセスにシグナルを送信し、シグナルを受信した親プロセスは関数を呼び出して AOF 書き換えバッファーの内容を新しい AOF ファイルに書き込みます
   。
   これにより、サーバーに対する AOF 書き換えの影響が最小限に抑えられます。

AOFのメリットとデメリット

アドバンテージ：

1. AOF 永続化方式では、さまざまな同期頻度が提供されます。デフォルトの同期頻度を使用して 1 秒に 1 回同期した場合でも、最大 1 秒
   のデータが失われます。
2. AOF ファイルは Redis コマンドを追加する形式で構築されるため、Redis が AOF ファイルにコマンド フラグメントしか書き込めない場合でも、
   redis-check-aof ツールを使用して AOF ファイルを修正するのは簡単です。
3. AOF ファイルの形式は読みやすくなっているため、ユーザーはより柔軟な処理方法を利用できます。たとえば、誤って
   FLUSHALL コマンドを使用した場合、再書き込みする前に最後の FLUSHALL コマンドを手動で削除し、AOF を使用して
   データを復元できます。
   欠点:
4. 同じデータを持つ Redis の場合、通常、AOF ファイルは RDB ファイルよりも大きくなります。
5. AOF はさまざまな同期頻度を提供しますが、デフォルトでは 1 秒に 1 回の同期頻度でもパフォーマンスが高くなります。ただし、
   Redis の負荷が高い場合、RDB は AOF よりも優れたパフォーマンスを保証します。
6. RDB はスナップショットを使用して Redis データ全体を永続化しますが、AOF は実行された各コマンドを AOF ファイルに追加するだけなので、
   理論上は RDB の方が AOF よりも堅牢です。
   公式ドキュメントでは、AOF には RDB には存在しないいくつかのバグがあることも指摘されています。

Redis パブリッシュ サブスクライブ

Redis パブリッシュ/サブスクライブ (pub/sub) はメッセージ通信モードです。送信者 (pub) がメッセージを送信し、サブスクライバー (sub) がメッセージを受信します。
Redis の submit コマンドを使用すると、クライアントは任意の数のチャネルをサブスクライブでき、サブスクライブしたチャネルに新しい情報が送信されるたびに、その情報は指定された
チャネルにサブスクライブしているすべてのクライアントに送信されます。
以下の図は、チャネル channel1 と、このチャネルをサブスクライブしている 3 つのクライアント (client2、client5、および client1) との関係を示しています。
新しい
メッセージがパブリッシュ コマンドを通じてチャネル channel1 に送信されると、このメッセージはその 3 つのサブスクリプションに送信されます。クライアント:
パブリッシュとサブスクライブを使用する理由は何ですか?
メッセージミドルウェアに詳しい学生は、メッセージのサブスクリプションとリリース機能に、市場の多くの大手メーカーが Kafka、RabbitMQ、
ActiveMQ、RocketMQ などを使用していることを知っています。これら 3 つと比較すると、redis のサブスクリプションとリリース機能は比較的軽量です。データの正確性とセキュリティ要件に直接使用できるため
、小規模企業に適しています。

Redis には 2 つのパブリッシュ/サブスクライブ モードがあります:
チャネル ベースのパブリッシュ/サブスクライブ
パターン ベースのパブリッシュ/サブスクライブ (自己学習)

チャネルベースのパブリッシュ/サブスクライブ操作コマンドは次のとおりです。

「パブリッシュ/サブスクライブ」には、パブリッシャーとサブスクライバーの 2 つの役割が含まれます。パブリッシャーは指定されたチャネルにメッセージを送信でき、サブスクライバーは
1 つ以上のチャネルをサブスクライブでき、このチャネルにサブスクライブしているすべてのサブスクライバーがこのメッセージを受信します。

--------------------------客户端1（订阅者） ：订阅频道 ---------------------
# 订阅 “mrtt” 和 “csdn” 频道（如果不存在则会创建频道）
127.0.0.1:6379> subscribe mrtt csdn
Reading messages... (press Ctrl-C to quit)
1) "subscribe" -- 返回值类型：表示订阅成功！
2) "mrtt" -- 订阅频道的名称
3) (integer) 1 -- 当前客户端已订阅频道的数量
1) "subscribe"
2) "csdn"
3) (integer) 2
#注意：订阅后，该客户端会一直监听消息，如果发送者有消息发给频道，这里会立刻接收到消息

チャンネルメッセージを公開する

--------------------------客户端2（发布者）：发布消息给频道 -------------------
# 给“mrtt”这个频道 发送一条消息：“I am mrtt”
127.0.0.1:6379> publish mrtt "I am mrtt"
(integer) 1 # 接收到信息的订阅者数量，无订阅者返回0

クライアント 2 (パブリッシャー) がチャネルにメッセージをパブリッシュした後、クライアント 1 (サブスクライバー) のクライアント ウィンドウの変化を観察してみましょう。

# --------------------------客户端1（订阅者） ：订阅频道 -----------------
127.0.0.1:6379> subscribe mrtt csdn
Reading messages... (press Ctrl-C to quit)
1) "subscribe" -- 返回值类型：表示订阅成功！
2) "mrtt" -- 订阅频道的名称
3) (integer) 1 -- 当前客户端已订阅频道的数量
1) "subscribe"
2) "csdn"
3) (integer) 2
---------------------变化如下：（实时接收到了该频道的发布者的消息）------------
1) "message" -- 返回值类型：消息
2) "mrtt" -- 来源（从哪个频道发过来的）
3) "I am mrtt" -- 消息内容

詳細については、https://blog.csdn.net/w15558056319/article/details/121490953 を参照してください。

Redisクラスター

redisのレプリケーション機能を利用してマスターとスレーブ(1対多)を作成します。マスターとスレーブは複数のデータベース間のデータ同期をサポートします。1 つはマスター データベース
(マスター ホスト)、もう 1 つはスレーブ データベース (スレーブ スレーブ) (マスター/スレーブ レプリケーション) の読み取りと書き込みの分離です。マスター データベースは読み取りおよび書き込み操作を実行できます。書き込み操作が発生すると、
データはスレーブ データベースに自動的に同期されます。スレーブ データベースは通常、読み取り専用 (読み取りと
書き込みの分離)
です。スレーブ マシンは、マスター データベースから同期されたデータを受信します。マスター データベースは複数のスレーブ データベースを持つことができ、スレーブ データベースは 1 つのスレーブ データベースのみを持つことができます。 redis による1 つのマスター データベース
(1 つのボスのみ)
データベースのレプリケーション機能により、データベースの読み取りと書き込みの分離がよく実現され、サーバーの負荷容量が向上します。マスター データベースは主に書き込み操作を実行し
、スレーブ データベースは読み取り操作を担当します。このように、操作の 80% のほとんどがデータの読み取りであるため、以前紹介したアーキテクチャ図では、読み取りと書き込みを分離する方法により、クラスターの
環境でもあるサーバーへの負荷を軽減できます。

※通常は最小構成としてマスター1台、スレーブ2台の構築方法を推奨します。
マスタ・スレーブ・レプリケーション（redisクラスタ）の役割
#1 データ冗長性：マスタ・スレーブ・レプリケーションは、永続化以外のデータ冗長化手法であるデータのホット・バックアップを実現するものであり、ビッグデータの分野では
一般的にデータストレージは複数のコピー
#2 データディザスタリカバリ (障害復旧): マスターノードに問題が発生した場合、スレーブノードがサービスを提供して高速障害サービスを実現
#3 ロードバランシング: マスター/スレーブレプリケーションに基づいて、これにより、読み取りと書き込みの分離が実現し、同時実行量が増加します。
#4 高可用性 (クラスター) ベース: マスター/スレーブ レプリケーションはセンチネルとクラスター実装の基礎であるため、redis マスター/スレーブ レプリケーションは高可用性の基礎 (クラスター環境の基礎) # したがって、実際のプロジェクトでは、次のことが可能
です
。スタンドアロン モードは基本的に、高可用性と高い同時実行性を実現するために Redis クラスターを構築します。

クラスタインフラ構築（シングルマシンマルチクラスタ）

基本的なコマンド

# info 查看所有配置信息 -- 信息太多。
# info server 服务器信息
# info clients 表示已连接客户端信息
# info cpu CPU 计算量统计信息
# info replication 主从复制信息 **************************

まずは現在の環境情報を確認してください

# Replication
role:master #表示当前环境为主机
connected_slaves:0 #集群从机连接的数量
master_failover_state:no-failover
master_replid:a38595b7159c4f304a57e43c6352259afd396799
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

準備

#ストレージ方式を rdb に変更
#1 マスター 2 スレーブ クラスター 6379 6380 6381 を構築
#さらに 2 つの redis-config ファイルをコピーし、対応するポート番号と dump6379.rdb dump6380.rdb dump6381.rdb
#pidfile レコード ファイルを変更
#起動ログを変更ファイル名

# 主机配置 - 6379
# 主机端口port --> 6379 不用修改
# pidfile --> 守护进程产生的文件 默认redis_6379 主机也不用改
# 日志logfile --> 改成"6379.log"
# 数据库文件dbfilename --> dump6379.rdb
#从机配置-1 6380
# 主机端口port --> 6380
# pidfile --> 守护进程产生的文件 默认redis_6380
# 日志logfile --> 改成"6380.log"
# 数据库文件dbfilename --> dump6380.rdb
#从机配置-2 6381
# 主机端口port --> 6381
# pidfile --> 守护进程产生的文件 默认redis_6381
# 日志logfile --> 改成"6381.log"
# 数据库文件dbfilename --> dump6381.rdb

クラスターを開始する

# 6379 を開始

[root@sunwz redis-7.0.4]# redis-server sunwz/redis6379.conf
[root@sunwz redis-7.0.4]# ps -ef | grep redis
root 66509 1 0 00:06 ? 00:00:00 redis-server *:6379
root 66841 65483 0 00:06 pts/0 00:00:00 grep --color=auto redis
[root@sunwz redis-7.0.4]# redis-cli -p 6379 --raw
127.0.0.1:6379> info replication
# Replication
role:master # 主机
connected_slaves:0
master_failover_state:no-failover
master_replid:a283a0746770b978c00c1768146261d82fe5038c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>

6380を開始

[root@sunwz redis-7.0.4]# redis-server sunwz/redis6380.conf
[root@sunwz redis-7.0.4]# ps -ef | grep redis
root 66509 1 0 00:06 ? 00:00:00 redis-server *:6379
root 68472 65483 0 00:07 pts/0 00:00:00 redis-cli -p 6379 --raw
root 75357 1 0 00:11 ? 00:00:00 redis-server *:6380
root 76045 71194 0 00:12 pts/2 00:00:00 grep --color=auto redis
[root@sunwz redis-7.0.4]# redis-cli -p 6380 --raw
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:1d2881d7dd50bee528ace73c2129b33f3373cf2a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

スタート6381

[root@sunwz redis-7.0.4]# redis-server sunwz/redis6381.conf
[root@sunwz redis-7.0.4]# ps -ef | grep redis
root 66509 1 0 00:06 ? 00:00:00 redis-server *:6379
root 68472 65483 0 00:07 pts/0 00:00:00 redis-cli -p 6379 --raw
root 75357 1 0 00:11 ? 00:00:00 redis-server *:6380
root 77552 71194 0 00:12 pts/2 00:00:00 redis-cli -p 6380 --raw
root 83211 1 0 00:14 ? 00:00:00 redis-server *:6381
root 83748 80750 0 00:15 pts/4 00:00:00 grep --color=auto redis
[root@sunwz redis-7.0.4]# redis-cli -p 6381 --raw

1 マスター 2 スレーブ構成

#デフォルトでは、各 Redis サーバーはマスター ノードであるため、スレーブ マシンを構成するだけで済みます。！
#クライアントに個別に接続します (対応するポートにログインします) 情報レプリケーションを通じて状況を確認します (デフォルトはホストです)

マスター(6379) スレーブ(6380,6381)

設定コマンド

IPポートのスレーブ

#===========6380认老大==============
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
#=============6381认老大===============
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
# ==============查看主机==============
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=168,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=168,lag=1

テスト: データが同期されているかどうか。
注: ここで使用するのはコマンド設定です。サーバーを再起動すると、設定は消えます。実際のエンタープライズ環境は、
永続的な設定である設定ファイルで設定されます。

読み取りと書き込みの分離 (デフォルト)

Redis がマスター/スレーブ レプリケーションを実装すると、デフォルトで読み取りと書き込みが分離されます。データを設定したい場合は、マスターホストにのみ保存できます。

# 主机--写
# 从机--读
# 并且主机中所有的数据都会被从机保存

#スレーブ書き込みデータのテスト

127.0.0.1:6380> set k110 ceshi
(error) READONLY You can't write against a read only replica.
127.0.0.1:6380>

#ホストマシンがダウンしていてもスレーブマシンが正常に読み取れるかどうかをテストします

127.0.0.1:6380> keys *
1) "k1" #值存在
127.0.0.1:6380> info replication
# Replication
role:slave #并且依然是从机模式
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0

#テストしてホストを復元し、まだ同期できるかどうかをテストします (可能)
概要: ホストは切断され、スレーブは引き続きデータを正常に取得できますが、書き込み操作はありません。ホストが回復すると、データはまだ取得できます。同期される (高可用性
)

#スレーブ マシンがダウンしていることをテストします。ホストはデータの追加を続け、スレーブ マシンがデータを取得できるかどうかを確認し、新しい接続後にデータを追加し続けてデータを取得できるかどうかを確認します。

127.0.0.1:6380> shutdown
not connected> exit
[root@sunwz redis-7.0.4]# redis-server sunwz/redis6380.conf
[root@sunwz redis-7.0.4]# redis-cli -p 6380 --raw
127.0.0.1:6380> get u
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:d7cead93f6383df180b3c1de6750d425049c8612
master_replid2:c84b86fcd5b2f7d723431edbfe33d1d4abf28152
master_repl_offset:7661
second_repl_offset:7662
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:7662
repl_backlog_histlen:0
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6380> get u
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_read_repl_offset:7928
slave_repl_offset:7928
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:c84b86fcd5b2f7d723431edbfe33d1d4abf28152
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:7928
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:7929
repl_backlog_histlen:0
127.0.0.1:6380> keys *
stu
u
ww
name
127.0.0.1:6380> get u
123
127.0.0.1:6380>

スレーブ マシンがダウンした後、残りの 1 台のマスターと 1 台のスレーブは、現時点では正常に動作できます。スレーブ マシン 6380 が回復した後、データを直接同期することはできません。これは、コマンドによってマウントされたホストがデフォルトで現在のホストに設定されるためです
。再起動後、マスターとして 6380 を使用します。続行する場合は、このクラスター環境を維持するには、
ホスト ポートのスレーブを介してボスを再度指定する必要があります。その後、すべてのデータがスレーブに同期されます。

#クラスターが構成ファイルを使用して構築されている場合、上記の問題は回避できますか。
設定ファイルを変更する

# replicaof <masterip> <masterport>
# replicaof 127.0.0.1 6379 #将当前6381 挂载到6379上

スレーブを再起動します

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_read_repl_offset:8754
slave_repl_offset:8754
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:c84b86fcd5b2f7d723431edbfe33d1d4abf28152
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:8754
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8279
repl_backlog_histlen:476
127.0.0.1:6381> keys *
ww
name
stu
u