目次
2.3 Redis マスター/スレーブ レプリケーションのセットアップ
4.3 Redis クラスターのマスター/スレーブ レプリケーション モデル
序文
Redis クラスターにはマスター/スレーブ同期/レプリケーション、センチネル モード、クラスターの 3 つのモードがあり、この記事では 3 つのモードの仕組みとクラスターの構築方法について説明します。
1. モデルの紹介
1.1 マスター/スレーブレプリケーション
- マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel と Cluster はどちらもマスター/スレーブ レプリケーションに基づいて高可用性を実現します。マスター/スレーブ レプリケーションでは、主にデータのマルチマシン バックアップのほか、読み取り操作の負荷分散と単純な障害回復が実装されます。
- 欠点: 障害回復を自動化できない、書き込み操作の負荷分散ができない、ストレージ容量が 1 台のマシンによって制限される。
1.2 センチネル
- Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。
- 欠点: 書き込み操作は負荷分散できません; ストレージ容量は 1 台のマシンによって制限されます; Sentinel はスレーブ ノードの自動フェイルオーバーを実行できません 読み取り/書き込み分離シナリオでは、スレーブ ノードに障害が発生すると読み取りサービスが利用できなくなり、追加の監視が必要になりますスレーブノードのスイッチング動作が必要です。
1.3 クラスター
- Redis はクラスタリングを通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実装します。
2. マスター/スレーブ レプリケーション
- これは、1 つの Redis サーバーから他の Redis サーバーにデータをコピーすることを指します。前者をマスター ノード (Master)、後者をスレーブ ノード (Slave) と呼び、データ レプリケーションは一方向であり、マスター ノードからスレーブ ノードへのみ可能です。
- デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードを持たない) が、スレーブ ノードが持つことができるマスター ノードは 1 つだけです。
2.1 マスター/スレーブ レプリケーションの役割
●データの冗長化：マスタ・スレーブレプリケーションにより、データの永続化に加えてデータの冗長化方式であるホットバックアップを実現します。
●障害復旧：マスターノードで障害が発生した場合、スレーブノードがサービスを提供して迅速な障害復旧を実現しますが、これは一種のサービス冗長化です。
●負荷分散: マスター/スレーブのレプリケーションに基づいて、読み取りと書き込みの分離を組み合わせることで、マスター ノードが書き込みサービスを提供し、スレーブ ノードが読み取りサービスを提供できます (つまり、Redis データを書き込むとき、アプリケーションはマスターに接続します)ノードに接続し、Redis データを読み取るとき、アプリケーションはスレーブ ノードに接続してサーバー負荷を共有します。特に、書き込みが少なく読み取りが多いシナリオでは、複数のスレーブ ノードを通じて読み取り負荷を共有すると、Redis の同時実行性が大幅に向上します。サーバ。
●高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションはセンチネルやクラスターの実装の基礎でもあり、したがってマスター/スレーブ レプリケーションは Redis の高可用性の基礎となります。
2.2 マスター/スレーブ レプリケーション プロセス
(1) スレーブ マシンのプロセスが開始されると、「同期コマンド」コマンドをマスター マシンに送信して同期接続を要求します。
(2) 最初の接続であっても再接続であっても、マスター マシンはバックグラウンド プロセスを開始し、データ スナップショットをデータ ファイルに保存します (RDB 操作を実行します)。同時にマスターは、データベースを変更するためのすべてのコマンドも記録します。データを保存し、データ ファイルにキャッシュします。
(3) バックグラウンドプロセスによるキャッシュ操作が完了すると、マスターマシンはデータファイルをスレーブマシンに送信し、スレーブマシンはデータファイルをハードディスクに保存し、メモリにロードし、マスターマシンはデータファイルをスレーブマシンに送信します。変更されたすべてのデータを送信します。操作はスレーブ マシンにまとめて送信されます。スレーブに障害が発生してダウンタイムが発生した場合、正常に戻った後に自動的に再接続されます。
(4) マスター マシンがスレーブ マシンからの接続を受信した後、完全なデータ ファイルをスレーブ マシンに送信します。マスターがスレーブ マシンから同時に複数の同期要求を受信した場合、マスター マシンはバックグラウンドでプロセスを開始します。データ ファイルはすべてのスレーブ マシンに送信され、すべてのスレーブ マシンが正常であることを確認します。
2.3 Redis マスター/スレーブ レプリケーションのセットアップ
Master节点： 192.168.181.100
Slave1节点： 192.168.181.101
Slave2节点： 192.168.181.102
systemctl stop firewalld
setenforce 0
-----安装 Redis-----
yum install -y gcc gcc-c++ make
tar zxvf redis-5.0.7.tar.gz -C /opt/
wget -p /opt http://download.redis.io/releases/redis-5.0.9.tar.gz
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/bin/redis-server] /usr/local/redis/bin/redis-server
ln -s /usr/local/redis/bin/* /usr/local/bin/
-----修改 Redis 配置文件（Master节点操作）-----
vim /etc/redis/6379.conf redis.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
appendonly yes #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart
-----修改 Redis 配置文件（Slave节点操作）-----
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录 #288行，指定要同步的Master节点IP和端口
replicaof 192.168.181.100 6379
appendonly yes #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart
-----验证主从效果-----
在Master节点上看日志：
tail -f /var/log/redis_6379.log
Replica 192.168.181.101:6379 asks for synchronization
Replica 192.168.181.102:6379 asks for synchronization
在Master节点上验证从节点：
redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.181.101,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.181.102,port=6379,state=online,offset=1246,lag=13. Redis Sentinel モード
- マスター/スレーブ切り替え技術の方式は、サーバーがダウンした場合、スレーブ マシンを手動でマスター マシンに切り替える必要があり、手動による介入が必要となり、時間と労力がかかるだけでなく、故障の原因にもなります。サービスが一定期間利用できなくなる可能性があります。マスター/スレーブ レプリケーションの欠点を解決するために、センチネル メカニズムが導入されました。
- Sentinel のコア機能: Sentinel は、マスター/スレーブ レプリケーションに基づいて、マスター ノードの自動フェイルオーバーを導入します。
3.1 セントリーモードの原理
Sentinel:マスター/スレーブ構造内の各サーバーを監視するために使用される分散システムです。障害が発生すると、投票メカニズムを通じて新しいマスターが選択され、すべてのスレーブが新しいマスターに接続されます。したがって、Sentinel を実行するクラスター全体の数は 3 ノード以上である必要があります。
3.2 センチネルモードの役割
●監視: Sentinel はマスターノードとスレーブノードが正常に動作しているかどうかを常にチェックします。
●自動フェイルオーバー: マスター ノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始し、障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを複製するように変更します。マスターノードです。
●通知 (リマインダー): Sentinel はフェイルオーバーの結果をクライアントに送信できます。
3.3 センチネル構造
● Sentinel ノード: Sentinel システムは 1 つ以上の Sentinel ノードで構成され、Sentinel ノードはデータを保存しない特別な Redis ノードです。
●データノード: マスターノードとスレーブノードの両方がデータノードです。
3.4 Sentinel フェイルオーバー メカニズム
1. センチネル ノードは定期的に監視し、マスター ノードに障害が発生していないかを検出します。
各センチネル ノードは、ハートビート検出のために 1 秒ごとにマスター ノード、スレーブ ノード、および他のセンチネル ノードに ping コマンドを送信します。マスター ノードが特定の時間範囲内に応答しない場合、またはエラー メッセージで応答した場合、センチネルはマスター ノードが主観的に (一方的に) オフラインであると判断します。センチネル ノードの半数以上がマスター ノードが主観的にオフラインであると信じている場合、マスター ノードは客観的にオフラインになります。2. マスター ノードに障害が発生すると、センチネル ノードは Raft アルゴリズム (選挙アルゴリズム) を通じて選挙メカニズムを実装し、マスター ノードのフェイルオーバーと通知の処理を担当するリーダーとしてセンチネル ノードを共同で選出します。したがって、Sentinel を実行するクラスター全体の数は 3 ノード以上である必要があります。
3. リーダー センチネル ノードはフェイルオーバーを実行します｡そのプロセスは次のとおりです:
● スレーブ ノードを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを指すようにします
。スレーブノードと新しいマスターノードを指す マスターノード;
●マスターノードが交換されたことをクライアントに通知します。客観的オフラインはマスター ノードにのみ存在する概念であることに注意することが重要です。スレーブ ノードとセンチネル ノードに障害が発生した場合、センチネルによって主観的にオフラインになった後は、その後の客観的オフラインおよびフェイルオーバー操作は行われません。
#マスターノードの選択:
1.センチネルの ping 応答に応答しない、異常な (オフラインの) スレーブ ノードをフィルターで除外します。
2.構成ファイル内で最も優先度の高い構成を持つスレーブ ノードを選択します。(replica-priority、デフォルト値は 100)
3.最大のレプリケーション オフセットを持つスレーブ ノード、つまり最も完全なレプリケーションを選択します。Sentinel の起動はマスター/スレーブ モードに依存するため、Sentinel モードを開始する前にマスター/スレーブ モードをインストールする必要があります。
3.5 Redis 監視モードのセットアップ
Master节点：192.168.181.100
Slave1节点：192.168.181.101
Slave2节点：192.168.181.102
systemctl stop firewalld
setenforce 0
-----修改 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.181.100 6379 2 #84行，修改 指定该哨兵节点监控192.168.181.100:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000 #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #146行，故障节点的最大超时时间为180000（180秒）
-----启动哨兵模式-----
先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
-----查看哨兵信息-----
redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.181.100:6379,slaves=2,sentinels=3
-----故障模拟-----
#查看redis-server进程号：
ps -ef | grep redis
root 57031 1 0 15:20 ? 00:00:07 /usr/local/bin/redis-server 0.0.0.0:6379
root 57742 1 1 16:05 ? 00:00:07 redis-sentinel *:26379 [sentinel]
root 57883 57462 0 16:17 pts/1 00:00:00 grep --color=auto redis
#杀死 Master 节点上redis-server的进程号
kill -9 57031 #Master节点上redis-server的进程号
#验证结果
tail -f /var/log/sentinel.log
57742:X 07 Aug 2020 16:19:21.170 # +failover-state-select-slave master mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.170 # -sdown slave 192.168.80.12:6379 192.168.80.12 6379 @ mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.272 # +selected-slave slave 192.168.80.12:6379 192.168.80.12 6379 @ mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.272 * +failover-state-send-slaveof-noone slave 192.168.80.12:6379 192.168.80.12 6379 @ mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.338 * +failover-state-wait-promotion slave 192.168.80.12:6379 192.168.80.12 6379 @ mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.402 # -failover-abort-slave-timeout master mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.799 # -sdown master mymaster 192.168.80.11 6379
57742:X 07 Aug 2020 16:19:21.826 # +new-epoch 41
57742:X 07 Aug 2020 16:19:21.827 # +vote-for-leader b12178afd9f862e0ead00763c2c7f1ae7f5de22e 41
57742:X 07 Aug 2020 16:19:31.137 * +convert-to-slave slave 192.168.80.12:6379 192.168.80.12 6379 @ mymaster 192.168.80.11 6379
2.redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.181.101:6379,slaves=2,sentinels=3
4. Redis Rluster クラスターモード
- クラスター、つまり Redis クラスターは、 Redis 3.0 で導入された分散ストレージ ソリューションです。
- クラスターは複数のノード(Node)で構成され、Redisデータはこれらのノード間に分散されます。クラスター内のノードはマスター ノードとスレーブ ノードに分割されます。マスター ノードのみが読み取りおよび書き込みリクエストとクラスター情報の保守を担当し、スレーブ ノードはマスター ノードのデータとステータス情報のみを複製します。
4.1 クラスターの役割
(1) データ パーティショニング: データ パーティショニング (またはデータ シャーディング) は、クラスターの中核機能です。
クラスターはデータを複数のノードに分散します。一方で、Redis 単一マシンのメモリー サイズ制限を突破し、ストレージ容量を大幅に増加します。他方、各マスター ノードは外部の読み取りサービスと書き込みサービスを提供できるため、クラスターの応答性が向上します。
Redis スタンドアロン メモリ サイズの制限の問題は、永続性とマスター/スレーブ レプリケーションの導入時に言及されています。たとえば、スタンドアロン メモリが大きすぎる場合、bgsave と bgrewriteaof のフォーク操作によりメイン プロセスがブロックされる可能性があります。これにより、マスター/スレーブ環境でホストの切り替えが発生する可能性があり、その結果、スレーブ ノードが長時間サービスを提供できなくなり、完全なレプリケーション フェーズ中にマスター ノードのレプリケーション バッファーがオーバーフローする可能性があります。
(2) 高可用性: クラスターはマスター/スレーブ レプリケーションとマスター ノードの自動フェイルオーバー (Sentinel と同様) をサポートしており、いずれかのノードに障害が発生しても、クラスターは引き続き外部サービスを提供できます。
4.2 Redis クラスターのデータシャーディング
- Redis クラスターではハッシュ スロットの概念が導入されています
- Redis クラスターには 16384 個のハッシュ スロット (0 ～ 16383 の番号が付けられます) があります。
- クラスター内の各ノードは、ハッシュ スロットの一部を担当します。
- 各キーは CRC16 チェックに合格し、16384 の残りの部分を使用して配置するハッシュ スロットを決定します。この値を使用して、対応するスロットに対応するノードを見つけ、アクセス操作のために対応するノードに自動的にジャンプします。
#3 つのノードで構成されるクラスターを例に挙げます。
ノード A にはハッシュ スロット 0 ～ 5460 が含まれます。
ノード B にはハッシュ スロット 5461 ～ 10922 が含まれます。ノード
C にはハッシュ スロット 10923 ～ 16383 が含まれます。
4.3 Redis クラスターのマスター/スレーブ レプリケーション モデル
- クラスターには 3 つのノード A、B、C があります。ノード B に障害が発生すると、5461 ～ 10922 の範囲のスロットが不足するため、クラスター全体が使用できなくなります。
- 各ノードにスレーブ ノード A1、B1、C1 を追加すると、クラスター全体が 3 つのマスター ノードと 3 つのスレーブ ノードで構成されます。ノード B に障害が発生した後、クラスターはビット B1 でマスター ノードを選択してサービスを継続します。B と B1 の両方に障害が発生すると、クラスターは使用できなくなります。
4.4 Redis クラスターモードのセットアップ
Redis クラスターには通常、6 つのノード、3 つのマスター、3 つのスレーブが必要です。便宜上、ここでのすべてのノードは同じサーバー上でシミュレートされます。
ポート番号によって区別されます: 3 つのマスター ノードのポート番号: 6001/6002/6003、対応するスレーブ ノードのポート番号: 6004/6005/6006。
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
#开启群集功能：
#其他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持久化
#启动redis节点
分别进入那六个文件夹，执行命令：redis-server redis.conf ，来启动redis节点
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf
for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done
ps -ef | grep redis
#启动集群
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 才可以创建。
--replicas 1 表示每个主节点有1个从节点。
#测试群集
redis-cli -p 6001 -c #加-c参数，节点之间就可以互相跳转
127.0.0.1:6001> cluster slots #查看节点的哈希槽编号范围
1) 1) (integer) 5461
2) (integer) 10922 #哈希槽编号范围
3) 1) "127.0.0.1"
2) (integer) 6003 #主节点IP和端口号
3) "fdca661922216dd69a63a7c9d3c4540cd6baef44"
4) 1) "127.0.0.1"
2) (integer) 6004 #从节点IP和端口号
3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (integer) 0
2) (integer) 5460
3) 1) "127.0.0.1"
2) (integer) 6001
3) "0e5873747a2e26bdc935bc76c2bafb19d0a54b11"
4) 1) "127.0.0.1"
2) (integer) 6006
3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (integer) 10923
2) (integer) 16383
3) 1) "127.0.0.1"
2) (integer) 6002
3) "816ddaa3d1469540b2ffbcaaf9aa867646846b30"
4) 1) "127.0.0.1"
2) (integer) 6005
3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"
127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1:6003
OK
127.0.0.1:6001> cluster keyslot name #查看name键的槽编号
redis-cli -p 6004 -c
127.0.0.1:6004> keys * #对应的slave节点也有这条数据，但是别的节点没有
1) "name"