Redis クラスター
記事ディレクトリ
1.Redisクラスターモード
redis クラスターには、マスター/スレーブ同期/レプリケーション、センチネル モード、およびクラスターの 3 つのモードがあります. 以下では、3 つのモードの動作方法と、クラスター クラスターの構築方法について説明します。
- マスター/スレーブ レプリケーション: マスター/スレーブ レプリケーションは、高可用性 Redis の基盤です. Sentinel とクラスターは、高可用性を実現するためにマスター/スレーブ レプリケーションに基づいています. マスター/スレーブ レプリケーションは、主にデータのマルチマシン バックアップと、読み取り操作の負荷分散および単純な障害回復を実装します。
欠陥: 障害回復を自動化できない、書き込み操作の負荷分散ができない、ストレージ容量が 1 台のマシンに制限されている。 - Sentinel: マスター/スレーブ レプリケーションに基づいて、Sentinel は自動障害回復を実装します。
欠点: 書き込み操作の負荷分散ができない、ストレージ容量が 1 台のマシンによって制限される、Sentinel がスレーブ ノードを自動的にフェールオーバーできない、読み取りと書き込みの分離のシナリオでは、スレーブ ノードの障害により読み取りサービスが利用できなくなり、追加の監視が行われるスレーブノードが必要です。スイッチ操作。 - クラスター: Redis は、クラスター化によって、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。
2. Redis マスター/スレーブ レプリケーション
2.1 はじめに
マスター/スレーブ レプリケーションとは、ある Redis サーバーのデータを他の Redis サーバーにコピーすることを指します。前者をマスターノード(Master)、後者をスレーブノード(Slave)と呼び、データ複製はマスターノードからスレーブノードへの一方向のみです。
デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードを持たない) が、スレーブ ノードは 1 つのマスター ノードしか持てません。
2.2 機能
- データの冗長性: マスター/スレーブ レプリケーションは、データのホット バックアップを実装します。これは、永続性以外のデータ冗長性方法です。
- 障害復旧: マスター ノードに問題が発生した場合、スレーブ ノードがサービスを提供して迅速な障害復旧を実現できますが、これは実際には一種のサービス冗長性です。
- 負荷分散: マスター/スレーブ レプリケーションに基づいて、読み取り/書き込みの分離と組み合わせることで、マスター ノードは書き込みサービスを提供でき、スレーブ ノードは読み取りサービスを提供できます (つまり、Redis データの書き込み時にアプリケーションがマスター ノードに接続します)。 、および Redis データの読み取り時にアプリケーションがスレーブ ノードに接続する) 、サーバーの負荷を共有する; 特に書き込みを減らして読み取りを増やすシナリオでは、複数のスレーブ ノードを介して読み取り負荷を共有することで、Redis サーバーの同時実行性を大幅に向上させることができます。
- 高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションはセンチネルとクラスターの実装の基礎でもあるため、マスター/スレーブ レプリケーションは Redis の高可用性の基礎です。
2.3 マスター/スレーブ レプリケーション プロセス
- スレーブ マシン プロセスが開始されると、「同期コマンド」コマンドがマスター マシンに送信され、同期接続が要求されます。
- 最初の接続か再接続かに関係なく、マスター マシンはバックグラウンド プロセスを開始してデータ スナップショットをデータ ファイルに保存し (rdb 操作を実行)、マスターはデータを変更するすべてのコマンドを記録し、それらをキャッシュします。データファイル。
- バックグラウンド プロセスがキャッシュ操作を完了すると、マスター マシンはデータ ファイルをスレーブ マシンに送信し、スレーブ マシンはデータ ファイルをハード ディスクに保存してからメモリにロードします。データを変更するすべての操作を組み合わせて、スレーブ エンド マシンに送信します。スレーブに障害が発生してダウンタイムが発生した場合、正常に戻った後に自動的に再接続します。
- マスター マシンがスレーブ マシンからの接続を受信した後、完全なデータ ファイルをスレーブ マシンに送信します. マスターが同時に複数のスレーブから同期要求を受信した場合、マスターはデータを保存するためにバックグラウンドでプロセスを開始します.その後、すべてのスレーブ側マシンに送信して、すべてのスレーブ側マシンが正常であることを確認します。
2.4 マスター/スレーブ レプリケーションの構築
Redis サービスをインストールし
、3 台のサーバーに対して同じように構成します。
[root@lwb ~]# systemctl stop firewalld
[root@lwb ~]# setenforce 0
[root@lwb ~]# yum install -y gcc-c++ make
[root@lwb ~]# cd /opt
[root@lwb opt]# tar xf redis-5.0.7.tar.gz
[root@lwb opt]# cd redis-5.0.7/
[root@lwb redis-5.0.7]# make prefix=/usr/local/redis install
[root@lwb redis-5.0.7]# cd utils
[root@lwb utils]# ./install_server.sh
[root@lwb utils]# ln -s /usr/local/redis/bin/* /usr/local/bin
[root@lwb utils]# vim /etc/redis/6379.conf
それぞれの IP アドレスを書き留めます
[root@lwb utils]# /etc/init.d/redis_6379 restart
#可以在全局使用redis
[root@lwb utils]# ln -s /etc/init.d/redis_6379 /usr/local/bin/redis
#进入redis
[root@lwb utils]# redis-cli -h 192.168.36.40 -p 6379
Redisの設定ファイルを変更する（マスターノード操作）
[root@master ~]# vim /etc/redis/6379.conf
#第70行，修改监听地址
bind 0.0.0.0
第137行，开启守护进程
daemonize yes
#第172行，指定日志文件目录
logfile /var/log/redis_6379.log
#第264行，指定工作目录
dir /var/lib/redis/6379
#第288行，添加主服务器地址及端口
replicaof 192.168.48.11 6379
#第700行，开启AOF持久化功能
appendonly yes
[root@master ~]# /etc/init.d/redis_6379 restart
Redisの設定ファイルを変更する（スレーブノード操作）
2 つのスレーブの構成は同じです。
[root@slave1 ~]# vim /etc/redis/6379.conf
#第70行，修改监听地址
bind 0.0.0.0
第137行，开启守护进程
daemonize yes
#第172行，指定日志文件目录
logfile /var/log/redis_6379.log
#第264行，指定工作目录
dir /var/lib/redis/6379
#第287行，添加主服务器地址及端口
replicaof 192.168.36.30 6379
#第700行，开启AOF持久化功能
appendonly yes
[root@slave1 ~]# /etc/init.d/redis_6379 restart
マスター/スレーブ レプリケーションを確認する
マスター ノードのログを確認します: /var/log/redis_6379.log
サーバーから正常に同期されました
[root@master ~]# redis-cli -h 192.168.36.30 -p 6379 #登录数据库
info replication #查看主从同步信息
マスターにデータを作成する
スレーブで表示
3.セントリーモード
マスター/スレーブ切り替え技術の方法は次のとおりです。サーバーがダウンした場合、スレーブマシンをマスターマシンに手動で切り替える必要があります。これには手動の介入が必要であり、時間と労力がかかるだけでなく、サービスの原因にもなります。一定期間利用できなくなります。マスター/スレーブ レプリケーションの欠点を解決するために、センチネル メカニズムがあります。
Sentinel のコア機能:
マスター/スレーブ レプリケーションに基づいて、Sentinel はマスター ノードの自動フェイルオーバーを導入します。
センチネルモードの原理:
Sentinel は、マスター/スレーブ構造の各サーバーを監視するために使用される分散システムであり、障害が発生すると、投票メカニズムによって新しいマスターが選択され、すべてのスレーブが新しいマスターに接続されます。そのため、Sentinel を実行するクラスターの数は 3 ノード以上にする必要があります。
センチネルモードの役割:
- 監視: Sentry は、マスター ノードとスレーブ ノードが正常に機能していることを常にチェックします。
- 自動フェールオーバー: マスター ノードが正常に機能しない場合、Sentinel は自動フェールオーバー操作を開始します. 障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、代わりに他のスレーブ ノードが新しいマスター ノードをコピーできるようにします.
- 通知 (リマインダー): Sentinel はフェイルオーバーの結果をクライアントに送信できます。
センチネル構造は、セントリー ノードとデータ ノードの 2 つの部分で構成されます。
- Sentinel ノード: Sentinel システムは、データを保存しない特別な Redis ノードである 1 つ以上の Sentinel ノードで構成されます。
- データ ノード: マスター ノードとスレーブ ノードはどちらもデータ ノードです。
フェイルオーバーメカニズム
- センチネルノードはマスターノードに異常がないか定期的に監視し、
各センチネルノードはマスターノード、スレーブノード、その他のセンチネルノードに1秒ごとにpingコマンドを送信してハートビートを検出します。マスター ノードが特定の時間枠内に応答しないか、エラー メッセージで応答しない場合、センチネルはマスター ノードが主観的に (一方的に) オフラインであると見なします。センチネル ノードの半分以上がマスター ノードが主観的にオフラインであると考える場合、客観的にオフラインになります - マスター ノードに障害が発生すると、センチネル ノードは Raft アルゴリズム (選択アルゴリズム) を介して選択メカニズムを実装し、マスター ノードのフェイルオーバーと通知の処理を担当するリーダーとしてセンチネル ノードを共同で選択します。そのため、Sentinel を実行するクラスターの数は 3 ノード以上にする必要があります。
- フェールオーバーはリーダー センチネル ノードによって実行されます。プロセスは次のとおりです。
- スレーブ ノードを新しいマスター ノードにアップグレードし、他のスレーブ ノードが新しいマスター ノードを指すようにします
- 元のマスター ノードが回復すると、スレーブ ノードになり、新しいマスター ノードを指します。
- プライマリ ノードが交換されたことをクライアントに通知する
オブジェクティブ オフラインはマスター ノードに固有の概念であることに注意することが重要です。スレーブ ノードまたはセンチネル ノードに障害が発生し、センティネルによって主観的にオフラインにされた場合、その後のオブジェクティブ オフラインおよびフェイルオーバー操作はありません。
マスターノードの選出
- Sentinel ping 応答に応答しない異常な (オフラインの) スレーブ ノードを除外します。
- 構成ファイルで最も優先順位の高い構成を持つスレーブ ノードを選択します。(レプリカ優先度、デフォルトは 100)
- 最大のレプリケーション オフセット、つまり最も完全なレプリケーションを持つスレーブ ノードを選択します。
4.セントリーモードの設定
セントリーの起動はマスタースレーブモードに依存するため、センチネルモードを行う前にマスタースレーブモードをインストールする必要があります
#所有节点配置一样
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.36.30:6379这个主节点，该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.36.30 6379 2
#第113行，判定服务器down掉的时间周期，默认30000毫秒(30秒)
sentinel down-after-milliseconds mymaster 30000
#第146行，故障节点的最大超时时间为180000 (180秒)
sentinel failover-timeout mymaster 180000
セントリーモード開始
#先启动master，再启动slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
センチネル情報を表示する
redis-cli -p 26379 info sentinel
故障シミュレーション
マスター ノードの redis-server を表示して強制終了します
検証結果
センチネル情報を再度表示する
まとめ
Sentinel モードはマスター/スレーブ レプリケーションに基づいていますが、マスター/スレーブ レプリケーションは単一障害点の後に自動的に回復することができないため、サービスの高可用性を実現できません; Sentinel モードはマスター/スレーブ レプリケーションに基づいており、センチネル ノード検出を追加します。マスターがダウンすると、センチネル ノード サービスの高可用性を確保するために、投票によって新しいマスター サービスが選出されます。
5.Redisクラスターモード
クラスター、つまり Redis クラスターは、Redis 3.0 によって導入された分散ストレージ ソリューションです。
クラスターは複数のノード (ノード) で構成され、Redis データはこれらのノード間で分散されます。クラスター内のノードは、マスター ノードとスレーブ ノードに分けられます。マスター ノードのみが読み取りおよび書き込み要求とクラスター情報のメンテナンスを担当し、スレーブ ノードはマスター ノードのデータとステータス情報のみをレプリケートします。
5.1 クラスタの役割
1) データのパーティショニング: データのパーティショニング (またはデータ シャーディング) は、クラスターのコア機能です。
クラスターはデータを複数のノードに分散させます. 一方では, Redis 単一マシンのメモリサイズの限界を突破し, ストレージ容量が大幅に増加します. 一方, 各マスターノードは外部の読み取りおよび書き込みサービスを提供できます.これにより、クラスターの応答性が大幅に向上します。
Redis スタンドアロン メモリ サイズの制限は、永続性とマスター/スレーブ レプリケーションの導入で言及されています。たとえば、スタンドアロン メモリが大きすぎる場合、bgsave と bgrewriteaof のフォーク操作によってマスター プロセスがブロックされ、ホストが切り替わると、マスター/スレーブ環境が切り替わる可能性があり、その結果、スレーブ ノードが長時間サービスを提供できなくなり、マスター ノードのレプリケーション バッファがフル レプリケーション フェーズ中にオーバーフローする可能性があります。
2) 高可用性: クラスターは、マスター/スレーブ レプリケーションとマスター ノードの自動フェールオーバーをサポートします (Sentinel と同様): いずれかのノードに障害が発生した場合でも、クラスターは外部サービスを提供できます。
5.2 Redis クラスターのデータ断片化
Redis クラスターは、ハッシュ スロットの概念を導入します
Redis クラスターには 16384 個のハッシュ スロット (0 ～ 16383 の番号が付けられています) があります。
クラスターの各ノードは、ハッシュ スロットの一部を担当します。
各キーが CRC16 チェックに合格した後、16384 の残りを使用して、配置するハッシュ スロットを決定します. この値を通じて、対応するスロットに対応するノードを見つけ、アクセス操作のために対応するノードに直接かつ自動的にジャンプします
例として、3 つのノードで構成されるクラスターを取り上げます。
ノード A には 0 から 5460 までのハッシュ スロットが含まれ、
ノード B には 5461 から 10922 までのハッシュ スロットが含まれ、
ノード C には 10923 から 16383 までのハッシュ スロットが含まれます。
5.3 Redis クラスターのマスター/スレーブ レプリケーション モデル
クラスタには 3 つのノード A、B、および C があり、ノード B に障害が発生すると、5461 ～ 10922 の範囲のスロットが不足するため、クラスタ全体が使用できなくなります。
スレーブ ノード A1、B1、および C1 を各ノードに追加すると、クラスター全体が 3 つのマスター ノードと 3 つのスレーブ ノードで構成されます。ノード B に障害が発生した後、クラスターは B1 を持つマスター ノードを選択してサービスを継続します。B と B1 の両方に障害が発生すると、クラスターは使用できなくなります
6.Redisクラスターモードを構築する
通常、Redis クラスターには 6 つのノード (3 つのマスターと 3 つのスレーブ) が必要です。
ここでは、すべてのノードが同じサーバー上でシミュレートされ、ポート番号で区別されます。マスター ノードのポート番号は 6001、6002、6003 で、対応するスレーブ ノードのポート番号は 6004、6005、6006 です。
[root@master ~]# cd /etc/redis
[root@master redis]# mkdir -p redis-cluster/redis600{1..6}
[root@master redis]# for i in {1..6}
> do
> cp /opt/redis-5.0.7/src/redis-cli /etc/redis/redis-cluster/redis600$i
> cp /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
> done
6 つのリビジョンすべて
[root@master redis]# cd /etc/redis//redis-cluster/redis6001
[root@master redis6001]# ls
redis-cli redis.conf redis-server
[root@master redis6001]# vim redis.conf
#第69行，注释，即监听所有端口
#bind 127.0.0.1
#第88行，关闭保护模式
protected-mode no
#第92行，为了区分，将端口更改，6个不能相同
port 6001
#第136行，开启守护进程
daemonize yes
#第699行，开启AOF持久化
appendonly yes
#第832行，开启集群功能
cluster-enabled yes
#第840行，群集名称文件设置
cluster-config-file nodes-6001.conf
#第846行，群集超时时间设置
cluster-node-timeout 15000
redis-server 6379 プロセスを強制終了します
[root@master redis6006]# ps -ef | grep redis
root 1238 1 0 14:49 ? 00:00:06 /usr/local/bin/redis-server 0.0.0.0:6379
[root@master redis6006]# kill -9 1238
Redis ノードを開始する
[root@master redis6006]# for m in {1..6};do
> cd /etc/redis/redis-cluster/redis600$m/
> redis-server redis.conf
> done
クラスターを開始する
[root@master redis6006]# 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
# -replicas 1 表示每个主节点有1个从节点
#若使用6台服务器，此处节点ip请换为自己真实ip即端口号
クラスターテスト
redis-cli -p 6001 -c
#-c 参数，节点之间可以相互跳转
cluster slots
#查看节点的哈希槽编号范围
cluster keyslot 键名
#查看键的哈希槽编号
マスタースレーブの 3 つのセットを見ることができます
次に、6002 でキー値を作成し、6006 で確認します。キーが表示されます。キー値を確認すると、自動的に 6002 にジャンプします。6003 を使用してキー値を確認すると、空になりますが、 get を使用してキーの値を確認すると、ノード 6002 に対応するキーのハッシュ スロットに自動的にジャンプします。
