面试问Redis集群，被虐的不行了( 三 ) _Redis集群

文章插图

来到 data 目录下查看配置文件的变化。配置文件主要信息是每个主节点分的槽：

文章插图

文章插图

查看主机点的运行日志：这里给的主要信息 cluster status changed:ok 集群状态正常。

文章插图

⑤集群设置与获取数据
当直接设置数据会报错，并且把 name 这个 key 进行转化后的槽位置为 5798 并且给出了 ip 地址和端口号。

文章插图

需要使用命令 redis-cli -c，在进行设置值的时候提示说重定向到 5798 的这个槽。

文章插图

接下来进行获取数据，会自动的切换节点：

文章插图

故障转移
①集群从节点下线
根据上文集群启动信息知道端口 6383 是 6379 的从节点。接下来就是让 6383 下线查看 6379 的日志信息。
6379 会报出连接 6383 丢失，并且给上标记 fail，表示不可用。这个时候集群还是正常工作的。
总结：从节点下线对集群没有影响。

文章插图

当端口 6383 上线后，所有的节点会把 fail 的标记清除，如下图：

文章插图

②集群主节点下线
手动下线主节点 6379，查看从节点 6383 日志信息，此时的 6383 节点会持续连接 6379 共计 10 次，那为什么是 10 次呢?
是根据我们配置的参数 cluster-node-timeout 10 来决定的，这里给我们一个信息就是一秒连接一次。
直到时间到期后，开始故障转移。这时 6383 在故障转移选举中胜任，翻身奴隶把歌唱，成为了主节点。

文章插图

此时在查看一下集群的节点信息，命令 cluster nodes 。会发现这里竟然存在四个主节点，但是其中一个主节点时下线状态：

文章插图

6379 原主节点上线：6379 上线后，同样所有的节点也会清除 fail 信息。并且节点信息也会改变，此时的 6379 改变为 6383 的从节点。

文章插图

③新增主节点
再新增俩个端口 6385 和 6386：

文章插图

执行新增命令 ./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379，这里发送的就是 meet 消息。
执行 add-node 命令，第一个参数为新节点的 ip+端口，第二个参数为已存在集群中的节点。根据下图我们就可以看到新增的节点已经存在集群中了。
注意：虽说 6385 已经成为集群中的节点了，但是跟其它节点有区别。它没有数据，也就是没有哈希槽。

文章插图

接下来我们就需要把集群中的某些哈希槽分配到这个新节点上，分配结束后这个节点才会成为真正意义上的主节点。
执行命令 ./redis-trib.rb reshard 127.0.0.1:6385，会提示转移多少个哈希槽并填写接收节点的 id 。
最后一步询问是否从所有节点中转移：我使用的是 all 。使用指令：cluster nodes 查看，6385 的这个节点就已经拥有三个范围的哈希槽了。

文章插图

主节点已经新增好了，接下来就需要给 6385 这个主节点配置一个从节点 6386，命令如下：
./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0.0.1:6385
master-id 是 6385 的 id，第一个参数为新节点的 ip+端口，第二个为指定的主节点 ip+端口。