読み書き分離と組み合わせたマスター/スレーブレプリケーションに基づいて、マスターノードは書き込みサービスを提供し、スレーブノードは読み取りサービスを提供できます (つまり、アプリケーションは Redis データを書き込むときにマスターノードに接続し、アプリケーションは Redis データを読み取るときにスレーブノードに接続します)、サーバーの負荷を共有します。特に、書き込みが少なく読み取りが増えるシナリオでは、複数のスレーブノードで読み取り負荷を共有すると、Redis サーバーの同時実行性が大幅に向上します。

1.2.4高可用性の基礎

上記の機能に加えて、マスター/スレーブレプリケーションはセンチネルとクラスターの実装の基礎でもあり、マスター/スレーブレプリケーションは Redis の高可用性の基礎となります。

1.3 Redis のマスター/スレーブレプリケーションプロセス

スレーブマシンプロセスが開始されると、「同期コマンド」コマンドがマスターマシンに送信され、同期接続を要求します。
最初の接続であるか再接続であるかに関係なく、マスターマシンはバックグラウンドプロセスを開始してデータスナップショットをデータファイルに保存し (rdb 操作を実行)、またマスターはデータを変更するすべてのコマンドを記録し、データをキャッシュします。データファイル。
バックグラウンドプロセスがキャッシュ操作を完了すると、マスターマシンはデータファイルをスレーブマシンに送信し、スレーブマシンはデータファイルをハードディスクに保存してメモリにロードし、マスターマシンはデータを変更するすべての操作を組み合わせて、スレーブエンドマシンに送信します。スレーブに障害が発生してダウンタイムが発生した場合、通常に戻った後、自動的に再接続されます。
マスターマシンがスレーブマシンからの接続を受信した後、完全なデータファイルをスレーブマシンに送信します。マスターが複数のスレーブから同時に同期要求を受信した場合、マスターはデータを保存するためのプロセスをバックグラウンドで開始します。次に、それをすべてのスレーブ側マシンに送信して、すべてのスレーブ側マシンが正常であることを確認します。

1.4 Redis マスター/スレーブレプリケーションのデプロイ

1.4.1. 環境の展開

Master节点 192.168.40.172   redis-5.0.7.tar.gz
Slave1节点 192.168.40.170   redis-5.0.7.tar.gz
Slave2节点 192.168.40.17   redis-5.0.7.tar.gz

1.4.2. すべてのサーバーは最初にファイアウォールを閉じる必要があります

systemctl stop firewalld
setenforce 0
systemctl disable firewalld

1.4.3. Redis がすべてのサーバーにインストールされている

systemctl stop firewalld
setenforce 0
 
yum install -y gcc gcc-c++ make
 
tar zxvf redis-5.0.7.tar.gz -C /opt/
 
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
 
cd /opt/redis-5.0.7/utils
./install_server.sh
 
回车四次，下一步需要手动输入
 
Please select the redis executable path [] /usr/local/redis/bin/redis-server    
 
ln -s /usr/local/redis/bin/* /usr/local/bin/

1.4.4 Master マスターノード Redis の設定ファイルを変更する

vim /etc/redis/6379.conf
#70行，修改bind 项，0.0.0.0监听所有网段
bind 0.0.0.0
#137行，开启守护进程
daemonize yes
#172行，指定日志文件目录
logfile /var/log/redis_6379.log
#264行，指定工作目录
dir /var/lib/redis/6379
#700行，开启AOF持久化功能
appendonly yes
 
/etc/init.d/redis_6379 restart
netstat -natp | grep redis

1.6 マスター/スレーブ効果を確認する (192.168.40.17)

首先在Master上节点上查看日志
 
tail -f /var/log/redis_6379.log

1.6.1 マスターノード上のスレーブノードを確認する

redis-cli info replication

2.Redisセンチネルモード

Sentinel のコア機能: Sentinel は、マスター/スレーブレプリケーションに基づいて、マスターノードの自動フェイルオーバーを導入します。

2.1 センチネルモードの原理

Sentinel : マスター/スレーブ構造の各サーバーを監視するための分散システムであり、障害が発生した場合、投票メカニズムによって新しいマスターが選択され、すべてのスレーブが新しいマスターに接続されます。したがって、Sentinel を実行するクラスターの数は3 ノード以上である必要があります。

2.2 センチネルモードの役割

監視: Sentry はマスターノードとスレーブノードが適切に機能しているかどうかを常にチェックします。
自動フェイルオーバー: マスターノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始します。障害が発生したマスターノードのスレーブノードの 1 つを新しいマスターノードにアップグレードし、代わりに他のスレーブノードに新しいマスターノードを複製させます。。
通知 (リマインダー): Sentinel はフェイルオーバーの結果をクライアントに送信できます。

2.3 センチネルモードの構造

センチネル構造は、センチネルノードとデータノードの2 つの部分で構成されます。

Sentinel ノード: Sentinel システムは、データを保存しない特別な Redis ノードである 1 つ以上の Sentinel ノードで構成されます。
データノード:マスターノードとスレーブノードは両方ともデータノードです。

Sentinel の起動はマスター/スレーブモードに依存するため、マスター/スレーブモードのインストール後に Sentinel モードをインストールする必要があります。すべてのノードに Sentinel モードをデプロイする必要があります。Sentinel モードは、すべての Redis 動作ノードが正常であるかどうかを監視します。マスターが現れた場合他のノードがマスターノードと通信できなくなったため、問題が発生した場合に投票を行い、半数以上の投票があった場合はマスターに問題があるとみなし、監視室に通知され、スレーブの 1 人が新しいマスターとして選択されます。

特別な注意を払う必要があります: 客観的オフラインはマスターノードのみの概念です。スレーブノードとセンチネルノードに障害が発生した場合、主観的にオフラインになった後は、その後の客観的オフラインおよびフェイルオーバー操作は行われません。

2.4 フェイルオーバーメカニズム

2.4.1センチネルノードはマスターノードに障害がないかを定期的に監視します。

各センチネルノードは、ハートビートを検出するために、マスターノード、スレーブノード、および他のセンチネルノードに 1 秒ごとに ping コマンドを送信します。マスターノードが特定の時間枠内に応答しない場合、またはエラーメッセージで応答した場合、センチネルはマスターノードが主観的に (一方的に) オフラインであるとみなします。センチネルノードの半数以上が主観的にマスターノードがオフラインであると考えると、客観的にはオフラインになります。

2.4.2プライマリノードに障害が発生した場合

このとき、センチネルノードは、Raft アルゴリズム (選挙アルゴリズム) を通じて選挙メカニズムを実装し、マスターノードのフェールオーバーと通知の処理を担当するリーダーとしてセンチネルノードを共同で選出します。したがって、Sentinel を実行するクラスターの数は 3 ノード以上である必要があります。

2.4.3フェイルオーバーはリーダー監視ノードによって実行され、プロセスは次のとおりです。

スレーブノードを新しいマスターノードにアップグレードし、他のスレーブノードが新しいマスターノードを指すようにします。
元のマスターノードが回復すると、そのノードはスレーブノードになり、新しいマスターノードを指します。
プライマリノードが交換されたことをクライアントに通知します。

客観的オフラインはマスターノードに固有の概念であるという事実に特別な注意を払う必要があります。スレーブノードとセンチネルノードに障害が発生した場合、センチネルによって主観的にオフラインになった後は、その後の客観的オフラインおよびフェイルオーバー操作は行われません。

2.5 マスターノードの選択

センチネルの ping 応答に応答しない、異常な (オフラインの) スレーブノードをフィルターで除外します。
構成ファイル内で最も優先度の高い構成を持つスレーブノードを選択します。(レプリカの優先順位、デフォルト値は 100)
最大のレプリケーションオフセットを持つスレーブノード、つまり最も完全なレプリケーションを選択します。

セントリーの開始はマスター/スレーブモードに依存するため、センチネルモードを実行する前にマスター/スレーブモードをインストールする必要があります。

2.7 環境の準備

Master：192.168.40.17
Slave1：192.168.40.170
Slave2：192.168.40.172

2.8 Redis構成ファイルの変更(全ノード操作)

vim /opt/redis-5.0.7/sentinel.conf
protected-mode no     #17行，关闭保护模式
port 26379            #21行，Redis哨兵默认的监听端口
daemonize yes         #26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log"     #36行，指定日志存放路径
dir "/var/lib/redis/6379"           #65行，指定数据库存放路径
sentinel monitor mymaster 192.168.40.17 6379 2        #84行， 修改
指定该哨兵节点监控192.168.40.17:6379这个主节点，该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000   #113行,判定服务器down掉的时间周期，默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000        #146行，故障节点的最大超时时间为180000 (180秒 )

2.9 セントリーモードを開始して情報を表示する

cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
注意！先启动主服务器，再启动从服务器
redis-cli -p 26379 info Sentinel

2.10 故障シミュレーション

#在Master 上查看redis-server进程号:
ps -elf | grep redis
 
#杀死 Master 节点上redis-server的进程号
kill -9  redis进程号     #Master节点上redis-server的进程号
 
#验证master是转换至从服务器
tail -f /var/log/sentinel.log
 
#在Slave上查看是否转换成功
redis-cli -p 26379 INFO Sentinel

3. Redisクラスターモード

3.1 Redis クラスターの概念

クラスター、つまり Redis クラスターは、Redis 3.0 以降に導入された分散ストレージソリューションです。
クラスターは複数のノード (Node)で構成され、Redis データはこれらのノード間に分散されます。
クラスタ内のノードはマスターノードとスレーブノードに。マスターノードのみが読み取りおよび書き込みリクエストとクラスター情報のメンテナンスを担当します。スレーブノードはマスターノードのデータとステータス情報のみを複製します。

3.2 クラスターの役割

3.2.1 データパーティション

データのパーティショニング (またはデータシャーディング) はクラスターの中核機能です
クラスターはデータを複数のノードに分散します。一方で、Redis 単一マシンのメモリーサイズの制限を突破し、ストレージ容量が大幅に増加します。他方、各マスターノードは外部の読み取りおよび書き込みサービスを提供でき、これにより、クラスターの応答性が大幅に向上します。
Redis スタンドアロンメモリサイズの制限については、永続性とマスター/スレーブレプリケーションの紹介で説明されています。たとえば、スタンドアロンメモリが大きすぎる場合、bgsave と bgrewriteaof のフォーク操作によりメインプロセスがブロックされる可能性があり、マスター/スレーブ環境ではホストの切り替えが発生する可能性があり、その結果、スレーブノードが長時間サービスを提供できなくなり、フルレプリケーションフェーズ中にマスターノードのレプリケーションバッファがオーバーフローする可能性があります。

3.2.2 高可用性

クラスターは、マスター/スレーブレプリケーションとマスターノードの自動フェイルオーバー (Sentinel と同様) をサポートしており、いずれかのノードに障害が発生しても、クラスターは引き続き外部サービスを提供できます。

3.3 クラスターモードでのデータの断片化

Redis クラスターにはハッシュスロットの概念が導入されています
Redis クラスターには 16384 個のハッシュスロット (0 ～ 16383 の番号が付けられます) があります。
クラスターの各ノードはハッシュスロットの一部を担当します
各キーが CRC16 チェックに合格した後、16384 の残りを取得して、どのハッシュスロットに配置するかを決定します。この値を通じて、対応するスロットに対応するノードを見つけ、ノード上の対応するアクセス操作に直接かつ自動的にジャンプします。

<- - -3 つのノードで構成されるクラスターを例に挙げます- - ->
ノード A にはハッシュスロット 0 ～ 5460 が含まれます。ノード
B にはハッシュスロット 5461 ～ 10922 が含まれます。ノード
C にはハッシュスロット 10923 ～ 16383 が含まれます。

3.4 クラスタモードのマスタ/スレーブレプリケーションモデル

クラスターには 3 つのノード A、B、C があります。ノード B に障害が発生すると、5461 ～ 10922 の範囲のスロットが不足するため、クラスター全体が使用できなくなります。
各ノードにスレーブノード A1、B1、および C1 を追加すると、クラスター全体は 3 つのマスターノードと 3 つのスレーブノードで構成されます。ノード B に障害が発生した後、クラスターはサービスを継続するマスターノードとして B1 を選択します。B と B1 の両方に障害が発生すると、クラスターは使用できなくなります。

3.5 Redis クラスターのデプロイメント

3.5.1 環境の準備

Redis クラスターには通常、**6 ノード、3 つのマスター、3 つのスレーブ** が必要です。便宜上、ここではすべてのノードが 3 台のサーバー上でシミュレートされており、各ホストには IP アドレスとポートで区別される 1 つのマスターと 1 つのバックアップが設定されています。
3 つのマスターノードのポート番号: 6001、6002、6003
対応するスレーブノードのポート番号：7001、7002、7003

192.168.40.16 master
 
这里为了方便所有的节点都在同一台服务器上模拟

3.6 運用の準備

cd /etc/redis
mkdir -p redis-cluster/redis600{1..6}
 
for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done

3.7 クラスター機能をオンにする

他の 5 つのフォルダーの構成ファイルも同様に変更されており、6 つのポートは異なるはずです

cd /etc/redis/redis-cluster/redis6001
 
vim redis.conf
#bind 127.0.0.1                      #69行，注释掉bind项,默认监听所有网卡
protected-mode no                      #88行，修改，关闭保护模式
port 6001                              #92行，修改，redis监听端口，
daemonize yes                          #136行,开启守护进程,以独立进程启动
cluster-enabled yes                    #832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf    #840行，取消注释，群集名称文件设置
cluster-node-timeout 15000             #846行，取消注释群集超时时间设置
appendonly yes                         #700行，修改，开启AOF持久化

3.8 Redis ノードの起動

分别进入那六个文件夹，执行命令: redis-server redis.conf ，来启动redis节点
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf
 
for i in {1..6}
do
cd /etc/redis/redis-cluster/redis600$i
redis-server redis.conf
done
 
ps -ef | grep redis

3.9 クラスタの起動

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
 
yes

3.10 テストクラスター

redis-cli -p 6001 -c   #加-c参数，节点之间就可以互相跳转 
cluster slots     #查看节点的哈希槽编号范围
 
set test lisi
cluster keyslot test  #查看name键的槽编号

4. まとめ

1. マスター/スレーブレプリケーションは、データの複数マシンのバックアップだけでなく、読み取り操作や単純な障害回復のための負荷分散にも適しています。

2. Sentinel モードはマスター/スレーブレプリケーションに基づいています。Sentinel モードを導入するには、まずマスター/スレーブレプリケーションを導入する必要があります。これにより、マスター/スレーブレプリケーションに基づいて自動的に障害が回復されます。ただし、書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。

3. Redis クラスターは、書き込み操作の負荷分散ができず、単一マシンではストレージ容量が制限されるという問題を解決する分散ストレージソリューションを提供し、比較的完全な高可用性ソリューションを実現します。 Redis の高可用性を実現するためのノード、3 つのマスターと 3 つのスレーブ

Redis の 3 つのモード - マスター/スレーブ レプリケーション、センチネル モード、クラスター

1. マスター/スレーブ レプリケーション

1.1 マスター/スレーブ レプリケーションの概念

1.2 Redisマスタスレーブレプリケーション機能

1.2.1 データの冗長性

1.2.2 障害回復

1.2.3 負荷分散