記事のディレクトリ
序文
マスタースレーブレプリケーション：
- マスタースレーブレプリケーションは高可用性Redisの基盤であり、Sentinelとクラスターはすべてマスタースレーブレプリケーションに基づいており、高可用性を実現しています。
- マスタースレーブレプリケーションは、主にデータのマルチマシンバックアップ、および読み取り操作と単純な障害回復のための負荷分散を実装します
- 欠点は、障害回復を自動化できないこと、書き込み操作を負荷分散できないこと、およびストレージ容量が単一のマシンによって制限されることです。
歩哨：
- Sentinelは、マスタースレーブレプリケーションに基づいて、自動障害回復を実現します
- 欠点は、書き込み操作を負荷分散できず、ストレージ容量が1台のマシンによって制限されることです。
- また、歩哨はスレーブノードを自動的にフェイルオーバーできません。読み取り/書き込み分離シナリオでは、スレーブノードに障害が発生すると、読み取りサービスが使用できなくなり、スレーブノードで追加の監視および切り替え操作が必要になります。
集まる：
- クラスタリングを通じて、Redisは、書き込み操作の負荷分散が不可能であり、ストレージ容量が単一のマシンによって制限されるという問題を解決します
- 比較的完全な高可用性ソリューションが実現されました
1.Redisマスタースレーブレプリケーション
1。概要
- マスタースレーブレプリケーションとは、あるRedisサーバーのデータを他のRedisサーバーにコピーすることです。前者はマスターノードと呼ばれ、後者はスレーブノード（スレーブ）と呼ばれます。
- データレプリケーションは一方向であり、マスターノードからスレーブノードへのみです。
- デフォルトでは、各Redisサーバーはマスターノードであり、マスターノードは複数のスレーブノードを持つことができます（またはスレーブノードなし）が、スレーブノードは1つのマスターノードしか持つことができません
2.機能
データの冗長性：
- マスタースレーブレプリケーションは、データのホットバックアップを実現します
- 永続性以外のデータ冗長性方式です
回復：
- マスターノードに問題がある場合、スレーブノードは迅速な障害回復を実現するためのサービスを提供できます
- 実際には一種のサービス冗長性です
負荷分散：
- マスタースレーブレプリケーションに基づいて、読み取りと書き込みを分離することで、マスターノードは書き込みサービスを提供でき、スレーブノードは読み取りサービスを提供できます（つまり、アプリケーションはRedisデータの書き込み時にマスターノードに接続します、およびアプリケーションは、実際のRedisデータの場合にスレーブノードに接続し、サーバーの負荷を共有します
- 特に、書き込みを減らして読み取りを増やすシナリオでは、複数のスレーブノードで読み取り負荷を共有する
と、Redisサーバーの同時実行性が大幅に向上する可能性があります。
高可用性の基礎：
- 上記の機能に加えて、マスタースレーブレプリケーションはセンチネルとクラスターの実装の基礎でもあります
- したがって、マスタースレーブレプリケーションはRedisの高可用性の基盤です
3.プロセス
- スレーブマシンプロセスが開始されると、「syncコマンド」コマンドがマスターマシンに送信され、同期接続が要求されます。
- 最初の接続か再接続かに関係なく、マスターマシンはバックグラウンドプロセスを開始してデータスナップショットをデータファイルに保存し（RDB操作を実行）、マスターはデータを変更してキャッシュするすべてのコマンドも記録します。データファイル
- バックグラウンドプロセスがキャッシュ操作を完了した後、マスターマシンはデータファイルをスレーブマシンに送信し、スレーブマシンはデータファイルをハードディスクに保存してからメモリにロードします。その後、マスターマシンはデータファイルを送信します。データを変更するすべての操作を組み合わせます。スレーブマシンに送信されます。スレーブに障害が発生してダウンした場合、通常に戻った後、自動的に再接続します。
- マスターマシンはスレーブ側のマシンから接続を受信した後、完全なデータファイルをスレーブ側のマシンに送信します。Materが複数のスレーブから同時に同期要求を受信すると、マスターはバックグラウンドでプロセスを開始して、データファイル。次に、それをすべてのスレーブ側マシンに送信して、すべてのスレーブ側マシンが正常であることを確認します。
3、Redisマスタースレーブレプリケーションをビルドします
| ホスト | CPU名 | オペレーティング・システム | IPアドレス | メインソフトウェア |
|---|---|---|---|---|
| 主人 | CentOS 7-1 | CentOS 7 | 192.168.126.11 | イカ-3.5.28.tar.gz |
| スレーブ1 | CentOS 7-2 | CentOS 7 | 192.168.126.12 | イカ-3.5.28.tar.gz |
| スレーブ2 | CentOS 7-3 | CentOS 7 | 192.168.126.13 | イカ-3.5.28.tar.gz |
1.Redisをインストールします
- 3つのホストすべてにRedisをインストールする必要があります
- ソフトウェアパッケージポータルをダウンロードします：redis-5.0.7.tar.gz（抽出コード：qwer）
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
yum -y install gcc gcc-c++ make
cd /opt
#将软件包传至该目录下
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd redis-5.0.7/
make -j 4 && make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils/
./install_server.sh
#回车，直到出现以下选项，手动修改为“/usr/local/redis/bin/redis-server”
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/
netstat -natp | grep "redis"
#当 install_server.sh 脚本运行完毕，Redis 服务就已经启动，默认侦听端口为 6379
2.Redis構成ファイルを変更します
主人：
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，注释掉 bind 项，默认监听所有网卡
daemonize yes #137行，开启守护进程
logfile /var/1og/redis_ 6379.1og #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
appendonly yes #700行，开启 AOF 持久化功能
スレーブ：
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行，指定工作目录
replicaof 192.168.126.11 6379 #288行，指定要同步的 Master 节点 IP 和端口
appendonly yes #700行，开启 AOF 持久化功能
/etc/init.d/redis_6379 restart
#重启服务使配置生效
3.マスタースレーブ効果を確認します
マスターのログを見てください：
tail -f /var/log/redis_6379.log
マスターのスレーブノードを確認します。
redis-cli info replication
- そしてこの時、マスターだけで
3、Redisセンチネルモード
Sentinelのコア機能はマスタースレーブレプリケーションに基づいており、Sentinelはマスターノードの自動フェイルオーバーを導入します
1.原理と機能
センチネルモードの原理：
- Sentinelは、マスタースレーブ構造内の各サーバーを監視するために使用される分散システムです。障害が発生すると、投票メカニズムによって新しいマスターが選択され、すべてのスレーブが新しいマスターに接続されます。
- センチネルを実行しているクラスター全体の数は、3ノード以上である必要があります
センチネルモードの役割：
- 監視：歩哨は、マスターノードとスレーブノードが正常に動作しているかどうかを常にチェックします
- 自動フェイルオーバー：マスターノードが正常に機能しない場合、センチネルは自動フェイルオーバー操作を開始します。失敗したマスターノードのスレーブノードの1つを新しいマスターノードにアップグレードし、他のスレーブノードに新しいマスターノードをコピーさせます。
- 通知（リマインダー）：番兵はフェイルオーバーの結果をクライアントに送信できます
2.構造構成
センチネル構造は、センチネルノードとデータノードの2つの部分で構成されています。
- センチネルノード：センチネルシステムは、1つ以上のセンチネルノードで構成されています。センチネルノードは特別なredisノードであり、データを保存しません。
- データノード：マスターノードとスレーブノードの両方がデータノードです
3.作業プロセス
- センチネルの起動はマスタースレーブモードに依存するため、センチネルモードに移行する前にマスタースレーブモードをインストールする必要があります。すべてのノードがセンチネルモードをデプロイする必要があります。センチネルモードは、すべてのRedis作業ノードが正常かどうかを監視します。 。
- マスターに問題がある場合、他のノードがマスターノードとの接続を失うため、投票します。投票の半分以上はマスターに問題があると見なされ、その後、歩哨は歩哨がフェイルオーバー作業を実行するために選択されます（歩哨によって）どのスレーブを新しいマスターにするかを指定します）、次にスレーブから1つを新しいマスターとして選択します
- 選考方法は、センチネル同士がメッセージを送って投票に参加し、投票数の多い方を選出する方法です。
- 客観的オフラインはマスターノードでのみ利用可能な概念であることに注意することが重要です。つまり、スレーブノードとセンチネルノードに障害が発生した場合、センチネルが主観的にオフラインになった後、その後の客観的オフラインおよびフェイルオーバー操作（およびセンチネル）はありません。モードは、スレーブに関係なく、マスターの側面にのみ責任があります）
- センチネルは、マスターサーバーがダウンしていることを検出すると、マスターのSentinelRedistanceのマスターをSRI_S_DOWN（主観的にオフライン）に変更し、他のセンチネルにマスターがダウンしていることを通知します。
- 歩哨から送信された情報を受信した後、他の歩哨もマスターに接続しようとします。半分以上（構成ファイルで設定）がマスターがダウンしていることを確認すると、マスターのSentinelRedistanceのマスターは次のように変更されます。 SRI_O_DOWN（客観的に）行）
4.Redis歩哨モードを構築します
4.1Redis歩哨モードの設定ファイルを変更する
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.126.11 6379 2
#84行，修改，指定该哨兵节点监控 192.168.126.11:6379 这个主节点，该主节点的名称是 mymaster
#最后的 2 的含义与主节点的故障判定有关：至少需要 2 个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after -milliseconds mymaster 30000#113行，判定服务器 down 掉的时间周期，默认 30000毫秒 (30秒)
sentinel failover-timeout mymaster 180000 #146行，故障节点的最大超时时间为 180000 (180秒)
4.2セントリーモードの開始
最初にマスターを起動し、次にスレーブを起動します
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
4.3センチネル情報を表示する
redis-cli -p 26379 info Sentinel
4.4失敗をシミュレートする
ps -ef | grep "redis"
#查看 redis-server 的进程号
kill -9 [进程号]
#杀死 Master 节点上的 redis-server 的进程号
4.5検証結果
tail /var/log/sentinel.log
redis-cli -p 26379 info Sentinel
4、Redisクラスターモード
1。概要
- クラスター、つまりRedisクラスターは、Redis3.0によって導入された分散ストレージソリューションです。
- クラスターは複数のノード（ノード）で構成され、Redisデータはこれらのノードに分散されます。
- クラスター内のノードは、マスターノードとスレーブノードに分けられます。マスターノードのみが読み取りおよび書き込み要求とクラスター情報の保守を担当し、スレーブノードはマスターノードのデータとステータス情報のみを複製します。
2.機能
2.1データパーティション
- データ分割（またはデータシャーディング）はクラスターのコア機能です
- クラスターはデータを複数のノードに分散します。一方で、Redis単一マシンのメモリサイズ制限を突破し、ストレージ容量が大幅に増加します。他方、各マスターノードは外部の読み取りおよび書き込みサービスを提供できます。クラスターの応答性が大幅に向上します。
- 永続性とマスタースレーブレプリケーションの導入で言及された、Redisスタンドアロンメモリサイズ制限の問題
- たとえば、1台のマシンのメモリが大きすぎると、bgsaveとbgrewriteaofのフォーク操作によってマスタープロセスがブロックされ、マスターが切り替えられたときにスレーブノードが長期間サービスを提供できなくなる可能性があります。マスタースレーブ環境、およびマスターノードのレプリケーションバッファーが完全レプリケーション中にオーバーフローする可能性があります
2.2高可用性
- クラスターは、マスタースレーブレプリケーションとマスターノードの自動フェイルオーバー（センチネルと同様）をサポートします。いずれかのノードに障害が発生した場合でも、クラスターは外部サービスを提供できます。
2.2.1Redisクラスターのデータシャーディング
- Redisクラスターは、16384個のハッシュスロット（番号0〜16383）を備えたハッシュスロットの概念を導入しています。
- クラスタ内の各ノードは、ハッシュスロットの一部を担当します。各キーがCRC16によってチェックされた後、残りは16384で、配置するハッシュスロットを決定します。この値は、対応するスロットに対応するノードを見つけるために使用されます。その後、直接自動的にジャンプしますアクセス操作のために対応するノードに移動します
- 例として、3つのノードで構成されるクラスターを取り上げます。
- ノードAにはハッシュスロット0〜5469が含まれています
- ノードBにはハッシュスロット5461〜10922が含まれています
- ノードCにはハッシュスロット10923-16383が含まれています
2.2.2Redisクラスターのマスタースレーブレプリケーションモデル
- クラスターには3つのノードA、B、およびCがあります。ノードBに障害が発生すると、5461〜10922の範囲のスロットがないため、クラスター全体が使用できなくなります。
- 各ノードにスレーブノード（a、b、c）を追加します。つまり、クラスター全体に3つのマスターノードと3つのスレーブノードがあります。ノードBに障害が発生した後、クラスターはbを選択してマスターノードとして機能し続けます。 bすべての障害が発生すると、クラスター全体が使用できなくなります
5、Redisクラスターモードを構築する
1.準備
- 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
ls -R
2クラスター機能をオンにします
#其他五个文件夹的配置文件以此类推修改，注意六个端口都不一样
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行，开启守护进程，以独立进程启动
appendonly yes #699行，修改，开启 AOF 持久化
cluster-enabled yes #832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf #840行，取消注释，群集名称文件设置
cluster-node-t imeout 15000 #846行，取消注释群集超时时间设置
3.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"
4.クラスターを開始します
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 表示每个主节点有一个从节点
5.クラスターをテストします
redis-cli -p 6001 -c
#加 -c 参数，节点之间就可以互相跳转
127.0.0.1:6001> CLUSTER SLOTS
#查看节点的哈希槽编号范围
127.0.0.1:6001> set name wanger
-> Redirected to slot [5798] located at 127.0.0.1:6002
OK
#新建一个键的值
127.0.0.1:6002> CLUSTER KEYSLOT name
(integer) 5798
#查看 name 键的槽编号
ctrl+c
#退出
redis-cli -p 6001 -c
127.0.0.1:6001> KEYS *
(empty list or set)
127.0.0.1:6001>
ctrl+c
redis-cli -p 6005 -c
127.0.0.1:6005> KEYS *
1) "name"
#可以发现，对应的 slave 节点也有这条数据，但是别的节点没有