- ウルトラ詳細に、そしてより多くのグラフィック記述のRedisのRedisのクラスター・アプローチと擬似クラスタを設定

より多くのグラフィックの上、初心者の親しみやすさは抜群です。プロセスは、コマンドをノック、彼らは間違っをノックされますが、右の良い眺めを切断するために、小さな問題と、良い結果を実証するためには、スクラッチノックから開始する必要があります。私たちが見て、大切にしましょう。

理解RedisのクラスターあなたはRedisのを知りたい場合は、前のスタンドアローンバージョンは、閲覧することができspringboot統合Redisのを。さて、以下を開始します。

各インスタンスは、ノードのRedisと呼ばれ、デフォルトポートRedisのノードが別のポート、新しいノードを起動するために閉じられていない開始インストールされてもよいです。別のマシンでもインストールRedisの、新しいノードを起動します。

スレーブノードの複数のマスターノードからノードサブマスターノード（マスター）,,データ同期スレーブノード（スレーブ）。

redis3.0クラスタをサポートするために始めたとき、クラスターが均一Redisの入口ではなく、クラスタに接続されたクラスタ内の任意のノード（ノード）に接続されたクライアント（クライアント）は、クラスタは内部ノード（PING-PONG機構が相互に通信であります）。

@ [ヒール]

まず、クラスタのアプローチ

図1に示すように、マスタおよびスレーブモード

マスタは、複数のスレーブを有することができるが、スレーブがマスターのみに対応することができます。スレーブがマスタの読み書きに影響を与えるし、再起動した後、他のスレーブの読まずにハングアップしたときにこのように、データが同期マスタから来ます。

マスタースレーブモードでは、唯一のマスターノードがあるので書かれ、メインすることができ、ノードから読み取ることができ、それはノードが読書から責任がある、マスターノードを記述するための通常責任があります。

 唯一のマスターが、これは読書スレーブには影響を与えませんが、もはや書き込みサービスを提供するのRedisものの、後にハングアップする場合しかし、あなたは再Redisのは、外部の書き込みサービスを提供するだけに、再起動後にマスターする必要があります。

2、センチネルモード

センチネルモデルは、単一のマスタが後にハングアップ回避に基づいて、マスタ・スレーブモードに基づいており、書き込みサービスを提供していないのRedis。マスタは、スレーブがマスタとしてセンチネルを選択し、それらのプロファイルを修正する場合、ノードからのすべてのデータのバックアップマスターノードので、次に吊り後に、他のスレーブのプロファイルは、このような特性を改変するslaveofこれらは、以前に設定したパスワードとして、新しいマスターを指すようになります。この場合、クライアントは直接のRedisに接続されていませんが、接続はセンチネルによって、特定のRedisのサービスを提供するために、IPアドレスとポートセンチネル。  マスターが再起動される前に、ハングアップした後、それはもはや新しいマスターが、スレーブとして、マスタデータ同期を受信しません。

3、クラスタモード

クラスタモデルは、複数のマシンに割り当てられた特定のルールRedisのデータによれば、動的拡張の複数のデータが両方のフロントダイに必要なセンチネルモード、データスライスの必要性に基づいています。  動的な拡張をサポートするためのモデルで、追加または削除ノードをオンラインにし、クライアントが読み書きするためにいずれかのマスターノードに接続することができますが、この時間は、スレーブの役割は、単にバックアップノード。動的な拡張を行うことができる理由として、主には使用Redisのクラスタ整合性ハッシュがないので、しかし、ハッシュスロットの使用。16384個のクラスタが置かれているスロットを決定するために、モジュロによってCRC16チェックの各キー16384をRedisのハッシュスロットを有し、各クラスタ・ノード・ハッシュスロットの一部を担っています。

これは非常に簡単に追加したり、削除ノードであるので、私は新しい新しいノードを追加したい場合は、例えば、私はちょうど来て、トレンチの既存のノード部分から取得する必要があります。私は、ノードを削除したい場合は、あなただけのノードを必要とします他のノードに移動する溝は、次いで、任意の溝無しノードAがクラスタから除去することができます。ハッシュスロットを追加またはクラスターの状態が利用できないことはありませんハッシュスロット番号を変更するノードを削除するようにするかどうか、サービスが停止していない別のノードへの1つのノードから移動することになるからです。

需要注意的是，该模式下不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。

二，搭建集群

这里就直接搭建较为复杂的Cluster模式集群，也是企业级开发过程中使用最多的。

1，准备工作

Linux可以连接外网，有wget（用于在线下载redis），系统安装好gcc环境，（不然编译redis会报错）。

2，下载、解压、移到指定目录，编译Redis

wget http://download.redis.io/releases/redis-5.0.4.tar.gz
tar xzf redis-5.0.4.tar.gz
mv redis-5.0.4  /usr/local/redis
cd /usr/local/redis/redis-5.0.4
make
make install

安装完成，在/usr/local/bin/目录下就会看见 

3，建redis各节点目录

mkdir /usr/local/redis-cluster
cd /usr/local/redis-cluster
mkdir -p 9001/data 9002/data 9003/data 9004/data 9005/data 9006/data
mkdir bin

最终目录结构如下 

4，redis集群的运行脚本

把之前安装好的redis的src目录下运行脚本拷贝过来，每个redis版本的运行脚本有细微差异，请以你自己的版本为准，就是下图绿色部分。

cd /usr/local/redis/redis-5.0.4/src
cp  mkreleasehdr.sh redis-benchmark redis-check-aof  redis-check-rdb redis-cli redis-sentinel redis-server redis-trib.rb /usr/local/redis-cluster/bin

 最终效果如下图所示 

5，批量复制redis实例

cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9001
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9002
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9003
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9004
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9005
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9006

最终效果图如下所示 

6，逐个修改redis配置

以 9001 的为例子，其余五个类似。

cd /usr/local/redis-cluster/9001
vi redis.conf

 打开配置文件，按 i进入编辑模式，按照出现的顺序，主要需要修改的地方是

• bind 192.168.119.128（绑定当前电脑的 IP，这是我虚拟机的，你绑定成你虚拟机的ip）
• port 9001（因为我这是一台机器运行6个redis实例，所以要启动6个实例，得为它配置6个不同的端口，若你是6台机器，默认的端口就行，无需更改）
• daemonize yes（这是设置是否后台启动 Redis，默认 no ，但是生产环境肯定要默认就开启 Redis，所以这里设置为 yes 。）
• pidfile /var/run/redis_9001.pid（_9001这个一定要和第一个配置的端口一样）
• dir /usr/local/redis-cluster/9001/data/（数据文件存放位置，我换成指定目录下存放）
• appendonly yes
• cluster-enabled yes（启动集群模式）
• cluster-config-file nodes9001.conf（9001这个也要和之前的端口对应）
• cluster-node-timeout 15000（超时时间）  完成以上修改，Esc退出编辑模式，输入:wq 保存并退出。 类似同样的操作操作再来五次。

若是对redis的配置文件有兴趣，我在学习的过程中找到个详细的翻译版，可点击链接进去学习。

redis配置中文翻译

7，逐个启动redis节点

cd /usr/local/redis-cluster
/usr/local/bin/redis-server /usr/local/redis-cluster/9001/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9002/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9003/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9004/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9005/redis.conf 
/usr/local/bin/redis-server /usr/local/redis-cluster/9006/redis.conf

运行效果如图所示  现在检查一下是否成功开启，如下图所示，都开启成功。

ps -el | grep redis

8，搭建集群

此时的节点虽然都启动成功了，但他们还不在一个集群里面，不能互相发现，测试会报错：(error) CLUSTERDOWN Hash slot not served。

/usr/local/redis-cluster/bin/redis-cli -h 192.168.119.128 -p 9001
keys *
set name mafly

如下图所示  解决报错，如果你是redis5.0以前的，你需要安装集群所需的ruby相关依赖

yum install ruby
yum install rubygems
cd /usr/local/redis-cluster/
gem install redis

这步若安装报错，请查看Could not find a valid gem 'redis'

如果你是redis5.0及之后的，无需安装ruby依赖，redis安装目录里内置了集群命令行工具 redis-trib ，它是一个 Ruby 程序， 这个程序通过向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片工作。

redis-cli --cluster create 192.168.119.128:9001 192.168.119.128:9002 192.168.119.128:9003 192.168.119.128:9004 192.168.119.128:9005 192.168.119.128:9006 --cluster-replicas 1

--cluster-replicas 1 这个指的是从机的数量，表示我们希望为集群中的每个主节点创建一个从节点。

红色选框是给三个主节点分配的共16384个槽点。

黄色选框是主从节点的分配情况。

蓝色选框是各个节点的详情。 

9，测试

现在通过客户端命令连接上，通过集群命令看一下状态和节点信息等

/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9001
cluster info
cluster nodes

效果图如下，集群搭建成功。  现在往9001这个主节点写入一条信息，我们可以在9002这个主节点取到信息，集群间各个节点可以通信。

现在往9001这个主节点写入一条信息，我们可以在9002这个主节点取到信息，集群间各个节点可以通信。

 set name lgx
 get name

三，故障转移

1，故障转移机制详解

1. 集群中的节点会向其它节点发送PING消息（该PING消息会带着当前集群和节点的信息），如果在规定时间内，没有收到对应的PONG消息，就把此节点标记为疑似下线。

2. 当被分配了slot槽位的主节点中有超过一半的节点都认为此节点疑似下线（就是其它节点以更高的频次，更频繁的与该节点PING-PONG），那么该节点就真的下线。

3. 其它节点收到某节点已经下线的广播后，把自己内部的集群维护信息也修改为该节点已事实下线。

4. 节点资格审查：然后对从节点进行资格审查，每个从节点检查最后与主节点的断线时间，如果该值超过配置文件的设置，那么取消该从节点的资格。

5. 准备选举时间：这里使用了延迟触发机制，主要是给那些延迟低的更高的优先级，延迟低的让它提前参与被选举，延迟高的让它靠后参与被选举。（延迟的高低是依据之前与主节点的最后断线时间确定的）

6. 选举投票：当从节点获取选举资格后，会向其他带有slot槽位的主节点发起选举请求，由它们进行投票，优先级越高的从节点就越有可能成为主节点，当从节点获取的票数到达一定数值时（如集群内有N个主节点，那么只要有一个从节点获得了N/2+1的选票即认为胜出），就会替换成为主节点。

7. 替换主节点：被选举出来的从节点会执行slaveof no one把自己的状态从slave变成master，然后执行clusterDelSlot操作撤销故障主节点负责的槽，并执行 clusterAddSlot把这些槽分配给自己，之后向集群广播自己的pong消息，通知集群内所有的节点，当前从节点已变为主节点。

8. 接管相关操作：新的主节点接管了之前故障的主节点的槽信息，接收和处理与自己槽位相关的命令请求。

2，故障转移测试

这是之前集群中具体节点的情况，我简化成如下，可以向上回看图片中的集群信息。  这里关闭该9001端口的进程，即模拟该主节点挂掉。

 netstat -tunlp | grep 9001
 kill 15705

 ログインハングRedisのノードがマスターノードを介してアクセス可能なサービスを、拒否されますまだ実行され、その後、再び、クラスタ内の情報を表示します

/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9001

/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9002

cluster nodes

 情報は、クラスタが以下になる前に要するに、   今マスターノードを、私は、クラスタの内部ノードを再確認、再起動をハングアップ、以下の通り続きます。

cd /usr/local/redis-cluster/

/usr/local/bin/redis-server /usr/local/redis-cluster/9001/redis.conf

/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9002

cluster nodes

 次のように一言で言えば、状況は今、クラスタ内のノードであります

出典：http://www.1994july.club/seojishu/