1. Redis クラスター ソリューションの比較
センチネルモード
redis3.0 より前のバージョンでは、クラスターを実装するには、通常、マスター ノードの状態を監視するためにセンチネル ツールが使用されます。
通常はマスタースレーブスイッチとなり、特定のスレーブがマスターとして使用されますが、センチネルの構成は若干複雑ですが、性能と高可用性に優れています。
一般に、特にマスター/スレーブ切り替えの瞬間に
アクセスが瞬間的に中断される状況があり
、1 つのマスターノードのみがセンチネルモードで外部サービスを提供するため、これはサポートできません。
同時実行性が高く、単一マスター ノードのメモリを大きく設定しすぎないでください。そうしないと、永続ファイルが大きすぎて、データの回復やマスターとスレーブの同期に影響します。
効率
高可用性クラスターモード
Redis クラスターは、複数のマスター/スレーブ ノード グループ
で構成される分散サーバー グループであり
、
レプリケーション、高可用性、断片化の特性を備えています
。Redisクラスターは必要ありません
Sentinel Sentinel は、ノードの削除とフェイルオーバー機能も実行できます。各ノードをクラスター モードに設定する必要がありますが、クラスター モードではありません。
コアノードは水平方向に拡張可能で、公式
ドキュメント数万ノードまで直線的に拡張できるとのこと(
公式推奨は1,000ノード以下
)。Redisクラスター
パフォーマンスと高可用性は以前のバージョンの Sentinel モードよりも優れており、クラスター構成は非常にシンプルです
2. Redis高可用性クラスター構築
Redisクラスターの構築
Redis クラスターには
少なくとも 3 つのマスター ノードが必要です
。ここでは 3 つのマスター ノードを構築し、マスターごとにスレーブ ノードを構築します。
ポイント, 合計 6 つの Redis ノードがあります。ここでは、6 つの Redis インスタンスが 3 台のマシンにデプロイされています。各マシンには 1 つのマスターと 1 つのスレーブがあります。クラスターを構築する手順は次のとおりです:
第一步：在第一台机器的/usr/local下创建文件夹redis‐cluster，然后在其下面分别创建2个文件夾如下
（1）mkdir ‐p /usr/local/redis‐cluster
（2）mkdir 8001 8004
第一步：把之前的redis.conf配置文件copy到8001下，修改如下内容：
（1）daemonize yes
（2）port 8001（分别对每个机器的端口号进行设置）
（3）pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件
（4）dir /usr/local/redis‐cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会丢失数据）
（5）cluster‐enabled yes（启动集群模式）
（6）cluster‐config‐file nodes‐8001.conf（集群节点信息文件，这里800x最好和port对应上）
（7）cluster‐node‐timeout 10000
(8)# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通
过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
(9)protected‐mode no （关闭保护模式）
(10)appendonly yes
如果要设置密码需要增加如下配置：
(11)requirepass yanqiuxiang(设置redis访问密码)
(12)masterauth yanqiuxiang(设置集群节点间访问密码，跟上面一致)
第三步：把修改后的配置文件，copy到8004，修改第2、3、4、6项里的端口号，可以用批量替换：
:%s/源字符串/目的字符串/g
第四步：另外两台机器也需要做上面几步操作，第二台机器用8002和8005，第三台机器用8003和8006
第五步：分别启动6个redis实例，然后检查是否启动成功
（1）/usr/local/redis‐5.0.3/src/redis‐server /usr/local/redis‐cluster/800*/redis.conf
（2）ps ‐ef | grep redis 查看是否启动成功
第六步：用redis‐cli创建整个redis集群(redis5以前的版本集群是依靠ruby脚本redis‐trib.rb实现)
# 下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不
关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# 关闭防火墙
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动
# 注意：下面这条创建集群的命令大家不要直接复制，里面的空格编码可能有问题导致创建集群不成功
（1）/usr/local/redis‐5.0.3/src/redis‐cli ‐a yanqiuxiang‐‐cluster create ‐‐cluster‐replicas 1 192.168.30.130:8001 192.168.30.131:8002 192.168.30.132:8003 192.168.30.132:8004 192.168.0.62:8005 192.168.30.133:8006
第七步：验证集群：
（1）连接任意一个客户端即可：./redis‐cli ‐c ‐h ‐p (‐a访问服务端密码，‐c表示集群模式，指定ip地址
和端口号）
如：/usr/local/redis‐5.0.3/src/redis‐cli ‐a zhuge ‐c ‐h 192.168.30.130 ‐p 800*
（2）进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表）
（3）进行数据操作验证
（4）关闭集群则需要逐个进行关闭，使用命令：
/usr/local/redis‐5.0.3/src/redis‐cli ‐a yanqiuxiang‐c ‐h 192.168.30.130 ‐p 800* shutdown
3. Redisクラスタの原理の分析
Redis Cluster はすべてのデータを 16384 個のスロット (スロット) に分割し、各ノードがスロットの一部を担当します。スロット情報はそれぞれに保存されます
ノード内で。
Redis クラスターのクライアントがクラスターに接続すると、クラスターのスロット構成情報のコピーも取得され、クライアント上でローカルにキャッシュされます。これ
このようにして、クライアントは特定のキーを見つけたいときに、ターゲット ノードを直接見つけることができます。同時に、スロット情報がクライアントとサーバー間で異なる可能性があるため、
一貫性の場合、スロット情報の検証と調整を実現するための修正メカニズムが必要です。
スロット位置アルゴリズム
デフォルトでは、クラスターは crc16 アルゴリズムを使用してキー値をハッシュし、整数値を取得し、この整数値を 16384 を法として使用します。
特定のスロットを取得します。
HASH_SLOT = CRC16(キー) mod 16384
ジャンプ再配置
クライアントが間違ったノードに命令を送信すると、ノードは命令のキーが配置されているスロットがそれ自体によって管理されていないことに気づきます。
クライアントは、ターゲット操作のノード アドレスを含む特別なジャンプ コマンドを送信し、データを取得するためにこのノードに接続するようにクライアントに指示します。クライアントは、
コマンドの後、操作のために正しいノードにジャンプするだけでなく、ローカル スロット マッピング テーブル キャッシュも同期的に更新および修正され、後続のすべてのキーは新しいスロットを使用します。
ビットマップ。
Redis クラスターノード間の通信メカニズム
Redis クラスター ノードは通信にゴシップ プロトコルを使用します
クラスターのメタデータ (クラスター ノード情報、マスターとスレーブの役割、ノードの数、各ノードで共有されるデータなど) を維持するには 2 つの方法があります。
公式とゴシップ
集中化:
利点はメタデータの更新と読み取りであり、タイムリー性が非常に高く、メタデータが変更されるとすぐに集中ストレージに更新されます。
ポイントが読み取られるとすぐにそれを認識できますが、欠点は、すべてのメタデータ更新の圧力が 1 か所に集中しているため、メタデータが発生する可能性があることです。
データストレージのプレッシャー。多くのミドルウェアは、Zookeeper を使用してメタデータを一元的に保存します。
gossip:
gossip プロトコルには、ping、pong、meet、fail などのさまざまなメッセージが含まれています。
meets
: ノードは新しく参加したノードに meet を送信し、新しいノードをクラスターに参加させます。その後、新しいノードは他のノードと通信を開始します。
手紙;
ping
: 各ノードは他のノードに ping を頻繁に送信します。この ping には、自身のステータスとそれ自体が維持するクラスターのメタデータが含まれており、相互にパススルーされます。
Pingによるメタデータの交換(自身が認識するクラスタノードの追加や削除、ハッシュスロット情報など)。
pong
: 自身のステータスやその他の情報を含む ping メッセージと meet メッセージの返信は、情報のブロードキャストと更新にも使用できます。
failed
: ノードが他のノードに障害が発生したと判断した後、他のノードにfailを送信して、指定したノードがダウンしていることを他のノードに通知します。
ゴシップ プロトコルの利点は、メタデータの更新が 1 か所に集中するのではなく、比較的分散され、更新リクエストがすべてのノードに次々に送信されることです。
更新には一定の遅延が発生するため、プレッシャーは軽減されますが、欠点は、メタデータの更新の遅延により、クラスターの一部の操作が遅れる可能性があることです。
ゴシップ通信用のポート 10000
各ノードには、ノード間のゴシップ通信専用のポートがあります。これは、独自のサービスのポート番号 + 10000 (7001 など) です。
ポート 17001 はノード間の通信に使用されます。各ノードは時々他のいくつかのノードに ping メッセージを送信し、他のいくつかのノードは
ポイントは ping メッセージを受信した後、pong メッセージを返します。