序文
前回のブログ：NoSQL Redisの構成と最適化で、redisの高可用性について説明したとき、高可用性を実現するためのテクノロジーには、主に永続性、マスタースレーブレプリケーション、センチネル、クラスターが含まれると述べました。前回は永続性についてのみ説明しました。 。、今回は、マスタースレーブレプリケーション、歩哨、クラスターのコンテンツを追加します。
1つは、Redisクラスターの紹介です
●マスタースレーブレプリケーション：高可用性Redisの基盤です。Sentinelとクラスターは、マスタースレーブレプリケーションに基づいて高可用性を実現します。マスタースレーブレプリケーションは、主にデータのマルチマシンバックアップ、および読み取り操作の負荷分散と単純な障害回復を実装します。欠陥：障害回復を自動化できない、書き込み操作を負荷分散できない、ストレージ容量が1台のマシンによって制限されている。
●センチネル：マスタースレーブレプリケーションに基づいて、センチネルは自動障害回復を実現します。欠陥：書き込み操作の負荷分散ができない、ストレージ容量が単一のマシンによって制限されている、センチネルがスレーブノードから自動的にフェイルオーバーできない。読み取りと書き込みの分離シナリオでは、スレーブノードに障害が発生すると読み取りサービスが使用できなくなります。スレーブノードの追加監視が必要です。スイッチ操作。
●クラスター：Redisは、クラスター化により、書き込み操作の負荷分散ができず、ストレージ容量が1台のマシンで制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。
2、Redisマスタースレーブレプリケーション
1.Redisマスタースレーブレプリケーションの概念
マスタースレーブレプリケーションとは、1つのRedisサーバーのデータを他のRedisサーバーにコピーすることです。前者はマスターノード（マスター）と呼ばれ、後者はスレーブノード（スレーブ）と呼ばれます。データレプリケーションは一方向であり、マスターノードからスレーブノードへのみ実行できます。
デフォルトでは、各Redisサーバーがマスターノードであり、マスターノードは複数のスレーブノードを持つことができます（またはスレーブノードなし）が、スレーブノードは1つのマスターノードしか持つことができません。
2.Redisマスタースレーブレプリケーションの役割
●データの冗長性：マスタースレーブレプリケーションは、データのホットバックアップを実現します。これは、永続性に加えてデータ冗長性の方法です。
●故障復旧：マスターノードに問題がある場合、スレーブノードは迅速な障害回復を実現するためのサービスを提供できます。実際、これは一種のサービス冗長性です。
●負荷分散：マスタースレーブレプリケーションに基づいて、読み取りと書き込みを分離することで、マスターノードは書き込みサービスを提供でき、スレーブノードは読み取りサービスを提供します（つまり、アプリケーションはRedisデータの書き込み時にマスターノードに接続します） 、およびアプリケーションは、Redisデータを読み取るときにスレーブノードに接続し、サーバーの負荷を共有します。特に、書き込みを減らして読み取りを増やすシナリオでは、複数のスレーブノードで読み取り負荷を共有すると、Redisサーバーの同時実行性が大幅に向上します。
●高可用性の基礎：上記の機能に加えて、マスタースレーブレプリケーションはセンチネルとクラスターの実装の基礎でもあるため、マスタースレーブレプリケーションはRedisの高可用性の基礎です。
3.Redisマスタースレーブレプリケーションプロセス
-
ステップ1：スレーブマシンプロセスが開始されると、「syncコマンド」コマンドがマスターマシンに送信され、同期接続が要求されます。
-
ステップ2：最初の接続か再接続かに関係なく、マスターマシンはバックグラウンドプロセスを開始してデータスナップショットをデータファイルに保存し（RDB操作を実行）、マスターはデータを変更するためのすべてのコマンドを記録し、それらをデータファイルにキャッシュします。
-
ステップ3：バックグラウンドプロセスがキャッシュ操作を完了した後、マストマシンはデータファイルをスレーブマシンに送信し、スレーブマシンはデータファイルをハードディスクに保存してからメモリにロードし、次にマスターマシンがデータを変更し、すべての操作がスレーブマシンに送信されます。スレーブに障害が発生してダウンタイムが発生した場合、通常に戻った後、スレーブは自動的に再接続します。
-
ステップ4：マスターマシンがスレーブ側のマシンから接続を受信すると、完全なデータファイルをスレーブ側のマシンに送信します。Materが複数のスレーブから同時に同期要求を受信すると、マスターはバックグラウンドでプロセスを開始します。 。データファイルを保存し、それをすべてのスレーブ側マシンに送信して、すべてのスレーブ側マシンが正常であることを確認します。
4.Redisマスタースレーブレプリケーションの構築
インストールパッケージリンクredis-5.0.7.tar.gz
Master节点: 192. 168.182.11 redis-5.0.7.tar.gz
Slave1节点: 192. 168.182.22 redis-5.0.7.tar.gz
Slave2节点: 192. 168.182.33 redis-5.0.7.tar.gz
5. Redis（すべてのホスト）をインストールします
yum install -y gcc gcc-c++ make
cd /opt
tar zxvf redis-5.0.7.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/redis/bin/redis-server
ln -s /usr/local/redis/bin/* /usr/local/bin/
6.マスターノードのRedis構成ファイルを変更します
マスター192.168.182.11
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
7.スレーブノードのRedis構成ファイルを変更します
（192.168.182.11）、（192.168.182.33）
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改bind 项，0.0.0.0监听所有网卡
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
replicaof 192.168.184.10 6379 #288行，指定要同步的Master节点IP和端口
appendonly yes #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart
8.マスタースレーブサービスを確認します
マスターノードからログを表示する
3、Redisセンチネルモード
哨兵的核心功能：在主从复制的基础上，哨兵引入了主节点的自动故障转移
1.センチネルモードの原理
- Sentinel：マスタースレーブ構造の各サーバーを監視するために使用される分散システムです。障害が発生すると、投票メカニズムによって新しいマスターが選択され、すべてのスレーブが新しいマスターに接続されます。したがって、センチネルを実行しているクラスター全体の数は3ノード以上である必要があります。
2.センチネルモードの役割
- 監視：番兵は、マスターノードとスレーブノードが正常に動作しているかどうかを常にチェックします。
- 自動フェイルオーバー：マスターノードが正常に機能しない場合、センチネルは自動フェイルオーバー操作を開始し、障害が発生したマスターノードのスレーブノードの1つを新しいマスターノードにアップグレードし、他のスレーブノードに新しいマスターノードをコピーさせます。
- 通知（リマインダー）：番兵はフェイルオーバーの結果をクライアントに送信できます。
3.センチネルモードの構造
センチネル構造は、センチネルノードとデータノードの2つの部分で構成されています。
- センチネルノード：センチネルシステムは、1つ以上のセンチネルノードで構成されます。センチネルノードは特別なredisノードであり、データを格納しません。
- データノード：マスターノードとスレーブノードの両方がデータノードです。
歩哨の開始はマスタースレーブモードに依存するため、歩哨モードを実行する前にマスタースレーブモードをインストールする必要があり、歩哨モードをすべてのノードに展開する必要があります。、センチネルモードは、すべてのRedis作業ノードが正常であるかどうかを監視します。マスターに問題がある場合、他のノードがマスターノードとの接続を失うため、投票します。投票の半分以上が問題であると見なされる場合マスター、歩哨室に通知され、新しいマスターとしてスレーブから1つを選択します。
注：目的オフラインはマスターノードでのみ使用できる概念です。スレーブノードとセンチネルノードに障害が発生した場合、センチネルが主観的にオフラインになった後は、その後の目的オフライン操作とフェイルオーバー操作は行われません。
4.センチネルモードの構築
環境構成：
上記の手順に従って、マスタースレーブレプリケーションがセットアップされました
Master节点: 192. 168.182.11 redis-5.0.7.tar.gz
Slave1节点: 192. 168.182.22 redis-5.0.7.tar.gz
Slave2节点: 192. 168.182.33 redis-5.0.7.tar.gz
5. Redis構成ファイルを変更します（すべてのノード操作）
vim /opt/redis-5.0.7/sentinel.conf
#17行，关闭保护模式
protected-mode no
#21行，Redis哨兵默认的监听端口
port 26379
#26行，指定sentinel为后台启动
daemonize yes
#36行，指定日志存放路径
logfile "/var/log/sentinel.log"
#65行，指定数据库存放路径
dir "/var/lib/redis/6379"
#84行，修改 指定该哨兵节点监控192.168.163.10:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.163.10 6379 2
#113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel down-after-milliseconds mymaster 30000
#146行，故障节点的最大超时时间为180000（180秒）
sentinel failover-timeout mymaster 180000
6.障害シミュレーション
redis-serverプロセス番号を表示する
マスターノードのredisサーバーのプロセスIDを強制終了します
マスターノードのredis-serverのプロセス番号を強制終了して
、マスターのダウンタイムをシミュレートします
7.検証結果
tail -f /var/log/sentinel.log
redis-cli -p 26379 INFO Sentinel
4、Redisクラスターモード
クラスター、つまりRedisクラスターは、Redis3.0で導入された分散ストレージソリューションです。
クラスターは複数のノード（ノード）で構成され、Redisデータはこれらのノードに分散されます。クラスター内のノードは、マスターノードとスレーブノードに分けられます。マスターノードのみが読み取りおよび書き込み要求とクラスター情報の保守を担当し、スレーブノードはマスターノードのデータとステータス情報のみを複製します。
1.クラスターの役割
（1）データパーティション：データ分割（またはデータシャーディング）は、クラスターのコア機能です。
クラスターはデータを複数のノードに分散します。一方で、Redis単一マシンのメモリサイズ制限を突破し、ストレージ容量が大幅に増加します。他方、各マスターノードは外部の読み取りおよび書き込みサービスを提供できます。クラスターの応答性が大幅に向上します。
Redisスタンドアロンメモリサイズの制限は、永続性とマスタースレーブレプリケーションの導入で言及されています。たとえば、スタンドアロンメモリが大きすぎる場合、bgsaveとbgrewriteaofのフォーク操作により、メインプロセスがブロックされる可能性があります。マスタースレーブ環境でホストを切り替えると、スレーブノードが長時間サービスを提供できなくなり、フルレプリケーションフェーズでマスターノードのレプリケーションバッファがオーバーフローする可能性があります。
（2）高可用性：クラスターは、マスタースレーブレプリケーションとマスターノードの自動フェイルオーバー（センチネルと同様）をサポートします。いずれかのノードに障害が発生した場合でも、クラスターは外部サービスを提供できます。
2.Redisクラスターのデータシャーディング
Redisクラスターはハッシュスロットの概念を導入しています
。Redisクラスターには16384個のハッシュスロット（番号0-16383）があり
ます。クラスター内の各ノードはハッシュスロットの一部を担当します。CRC16
チェックの後、各キーは16384の残りの部分を使用して決定します。どちらを配置するか。この値を使用して、対応するスロットに対応するノードを見つけるためにスロットを希望し、アクセス操作のために対応するノードに自動的にジャンプします。
＃例として、3つのノードで構成されるクラスターを取り上げます。
ノードAにはハッシュスロット
0〜5460が含まれ、ノードBに
はハッシュスロット5461〜10922が含まれ、ノードCにはハッシュスロット10923〜16383が含まれます。
#Redisクラスターのマスタースレーブレプリケーションモデル
クラスターには3つのノードA、B、およびCがあります。ノードBに障害が発生すると、5461〜10922の範囲のスロットがないため、クラスター全体が使用できなくなります。
各ノードにスレーブノードA1、B1、C1を追加します。クラスター全体は、3つのマスターノードと3つのスレーブノードで構成されます。ノードBに障害が発生した後、クラスターは、B1をメインノードとしてマスターノードを選択し、サービスを継続します。BとB1の両方に障害が発生すると、クラスターは使用できなくなります
3.Redisクラスターモードを構築します
redisクラスターには通常、6つのノード、3つのマスター、3つのスレーブが必要です。便宜上、ここのすべてのノードは6つのサーバーでシミュレート
されます。IPとポート番号で区別されます。3つのマスターノードのポート番号：7001、7003、7005、および対応するスレーブノードのポート番号：7002、7004、7006。
6つのサーバーすべてにredisデータベースをインストールする必要があります
| ホスト | オペレーティング・システム | IP：ポート | ソフトウェア/インストールパッケージ/ツール |
|---|---|---|---|
| マスター1 | CentOS7 | 192.168.182.11:7001 | redis-5.0.7.tar.gz |
| スレーブ1 | CentOS7 | 192.168.182.22:7002 | redis-5.0.7.tar.gz |
| マスター2 | CentOS7 | 192.168.182.33:7003 | redis-5.0.7.tar.gz |
| スレーブ2 | CentOS7 | 192.168.182.44:7004 | redis-5.0.7.tar.gz |
| マスター2 | CentOS7 | 192.168.182.55:7005 | redis-5.0.7.tar.gz |
| スレーブ2 | CentOS7 | 192.168.182.66:7006 | redis-5.0.7.tar.gz |
ここでのさまざまなノードの使用は、redisクラスターモードでポート6379だけでなくポートを指定できることを示したいだけです。ポートを変更したくない場合は、1つのポートを使用することもできるため、作成する方が便利です。ディレクトリを作成し、設定を変更します。リスニングIPを除くすべてのノード違い以外に違いはありません。
（1）関連ファイルの作成とコピー
#创建文件，文件名要根据端口创建，方便区别
cd /etc/redis/
mkdir -p redis-cluster/redis7001
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6371/
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6371/
（2）構成ファイルを変更してクラスター機能を有効にします
すべてのノードが
最初にノードを設定します
cd /etc/redis/redis-cluster/redis6371
vim redis.conf
#69行，修改bind项，监听自己的IP
bind 192.168.163.11
#88行，修改，关闭保护模式
protected-mode no
#92行，修改，redis监听端口
port 6371
#136行，以独立进程启动
daemonize yes
#699行，修改，开启AOF持久化
appendonly yes
#832行，取消注释，开启群集功能
cluster-enabled yes
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6371.conf
#846行，取消注释，群集超时时间设置
cluster-node-timeout 15000
このノードで構成されたファイルをコピーします
scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.163.12:/etc/redis/redis-cluster/redis6372/redis.conf
scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.163.13:/etc/redis/redis-cluster/redis6373/redis.conf
scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.163.14:/etc/redis/redis-cluster/redis6374/redis.conf
scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.163.15:/etc/redis/redis-cluster/redis6375/redis.conf
scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.163.16:/etc/redis/redis-cluster/redis6376/redis.conf
- 他のサーバー上
cd /etc/redis/redis-cluster/redis6372
vim redis.conf
#69行，修改bind项，监听自己的IP
bind 192.168.163.12
#92行，修改，redis监听端口
port 6372
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6372.conf
（3）redisノードを起動します
すべてのノード
#每台服务器进入对应的文件中，执行命令
cd /etc/redis/redis-cluster/redis6371/
redis-server redis.conf
ps -ef | grep redis
（4）クラスターを起動します
マスター1192.168.162.11:7001
redis-cli --cluster create 192.168.163.11:6371 192.168.163.12:6372 192.168.163.13:6373 192.168.163.14:6374 192.168.163.15:6375 192.168.163.16:6376 --cluster-replicas 1
（5）クラスターをテストします
redis-cli -h 192.168.162.11 -p 7001 -c #加-c参数，节点之间就可以互相跳转
cluster slots #查看节点的哈希槽编号范围
set test lisi
cluster keyslot test #查看name键的槽编号
構成が完了しました