公司有些项目会用到redis，但是目前大多数也只是单机玩玩，基本上和demo级别的使用差不多。所以我一般都是使用本地缓存（如caffeine）代替redis，更方便和快捷。redis的优势体现在分布式缓存，且数据量较大的情况。redis有很多高级用法，缓存只是他最简单和基础的功能罢了，持久化、主从复制、哨兵，集群，分布式锁，延时队列，位图bitmap，HyperLogLog，布隆过滤器，限流，GeoHash（附近的人）等等，眼花缭乱的类型和使用姿势多得不行。而对于集群这块，在前几年，redis 如果要搞几个节点，每个节点存储一部分的数据，得借助一些中间件来实现，比如说有 codis或者 twemproxy等 redis 中间件，你读写 redis 中间件，redis 中间件负责将你的数据分布式存储在多台机器上的 redis 实例中。

这两年，redis 不断在发展，redis 也不断有新的版本，现在的 redis 集群模式，一般在多台机器上，部署多个 redis 实例，每个实例存储一部分的数据，也叫数据分片（分而治之嘛）。同时每个 redis 主实例可以挂 redis 从实例，自动确保说，如果 redis 主实例挂了，会自动切换到 redis 从实例上来。现在 redis 的新版本，大家都是用 redis cluster 的，也就是 redis 原生支持的 redis 集群模式，而最新的redis6.0 已经原生支持代理了，就是Redis Cluster Proxy。

如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个 G，简单集群就足够了，可以使用 replication，一个 master 多个 slaves，要几个 slave 跟你要求的读吞吐量有关，然后自己搭建一个 sentinel 集群去保证 redis 主从架构的高可用性。

redis cluster，和哨兵的主要区别是它侧重于数据分片，承载大数据量的。主要是针对海量数据+高并发+高可用的场景。redis cluster 支撑 N 个 redis master node，每个 master node 都可以挂载多个 slave node。这样整个 redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。

特性

自动将数据进行分片，每个 master 上放一部分数据
提供内置的高可用支持，部分 master 不可用时，还是可以继续工作的

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379（关于redis作者为啥把6379作为默认端口，也是一段趣事哟），另外一个就是加1w 的端口号，比如 16379。16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

节点间的内部通信机制

基本通信原理

集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

集中式是将集群元数据（节点信息、故障等等）集中存储在某个节点上。集中式元数据集中存储的一个典型代表，就是大数据领域的 storm。它是分布式的大数据实时计算引擎，是集中式的元数据存储的结构，底层基于 zookeeper对所有元数据进行存储维护。

redis 维护集群元数据采用另一个方式， gossip 协议，所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。

集中式的好处在于，元数据的读取和更新，时效性非常好，一旦元数据出现了变更，就立即更新到集中式的存储中，其它节点读取的时候就可以感知到；不好在于，所有的元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。

gossip 好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续打到所有节点上去更新，降低了压力；不好在于，元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。

10000 端口：每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如 7001，那么用于节点间通信的就是 17001 端口。每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其它几个节点接收到 ping 之后返回 pong。
交换的信息：信息包括故障信息，节点的增加和删除，hash slot 信息等等。

gossip 协议

gossip 协议包含多种消息，包含 ping,pong,meet,fail 等等。

meet：某个节点发送 meet 给新加入的节点，让新节点加入集群中，然后新节点就会开始与其它节点进行通信。redis-trib.rb add-node，其实内部就是发送了一个 gossip meet 消息给新加入的节点，通知那个节点去加入我们的集群。

ping：每个节点都会频繁给其它节点发送 ping，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping 交换元数据。
pong：返回 ping 和 meeet，包含自己的状态和其它信息，也用于信息广播和更新。
fail：某个节点判断另一个节点 fail 之后，就发送 fail 给其它节点，通知其它节点说，某个节点宕机了。

ping 消息深入

ping 时要携带一些元数据，如果很频繁，可能会加重网络负担。

每个节点每秒会执行 10 次 ping，每次会选择 5 个最久没有通信的其它节点。当然如果发现某个节点通信延时达到了 cluster_node_timeout / 2，那么立即发送 ping，避免数据交换延时过长，落后的时间太长了。比如说，两个节点之间都 10 分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。所以 cluster_node_timeout 可以调节，如果调得比较大，那么会降低 ping 的频率。

每次 ping，会带上自己节点的信息，还有就是带上 1/10 其它节点的信息，发送出去，进行交换。至少包含 3 个其它节点的信息，最多包含 总节点数 - 2 个其它节点的信息。

分布式寻址算法

hash 算法（大量缓存重建）
一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
redis cluster 的 hash slot 算法

hash 算法

来了一个 key，首先计算 hash 值，然后对节点数取模。然后打在不同的 master 节点上。一旦某一个 master 节点宕机，所有请求过来，都会基于最新的剩余 master 节点数去取模，尝试去取数据。这会导致大部分的请求过来，全部无法拿到有效的缓存，导致大量的流量涌入数据库。

一致性 hash 算法

一致性 hash 算法将整个 hash 值空间组织成一个虚拟的圆环，整个空间按顺时针方向组织，下一步将各个 master 节点（使用服务器的 ip 或主机名）进行 hash。这样就能确定每个节点在其哈希环上的位置。

来了一个 key，首先计算 hash 值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，遇到的第一个 master 节点就是 key 所在位置。

在一致性哈希算法中，如果一个节点挂了，受影响的数据仅仅是此节点到环空间前一个节点（沿着逆时针方向行走遇到的第一个节点）之间的数据，其它不受影响。增加一个节点也同理。

燃鹅，一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成缓存热点的问题。为了解决这种热点问题，一致性 hash 算法引入了虚拟节点机制，即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。

笔者下次会专门写一篇java的TreeMap实现的一致性hash的代码实现。

hash slot 算法

redis cluster 有固定的 16384 个 hash slot，对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。

redis cluster 中每个 master 都会持有部分 slot，比如有 3 个 master，那么可能每个 master 持有 5000 多个 hash slot。hash slot 让 node 的增加和移除很简单，增加一个 master，就将其他 master 的 hash slot 移动部分过去，减少一个 master，就将它的 hash slot 移动到其他 master 上去。redis能保证移动 hash slot 的成本是非常低的。客户端的 api，可以对指定的数据，让他们走同一个 hash slot，通过 hash tag 来实现。

任何一台机器宕机，另外两个节点，不影响的。因为 key 找的是 hash slot，不是机器。

redis cluster 的高可用与主备切换原理

redis cluster 的高可用的原理，几乎跟哨兵是类似的。

判断节点宕机

如果一个节点认为另外一个节点宕机，那么就是 pfail，主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是 fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown。

在 cluster-node-timeout 内，某个节点一直没有返回 pong，那么就被认为 pfail。

如果一个节点认为某个节点 pfail 了，那么会在 gossip ping 消息中，ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成 fail。

从节点过滤

对宕机的 master node，从其所有的 slave node 中，选择一个切换成 master node。

检查每个 slave node 与 master node 断开连接的时间，如果超过了 cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成 master。

从节点选举

每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset 越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。

所有的 master node 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master。

从节点执行主备切换，从节点切换为主节点。

整个流程跟哨兵相比，非常类似，所以说，redis cluster 功能强大，直接集成了 replication 和 sentinel 的功能。

一、实操搭建

我们的目标是准备用一台虚拟机搭建三主三从端口从7001到7006的最简单的cluster集群，以下是笔记记录。

redis版本5.0.5


[root@applehubvm redis-cluster]# redis-server -v
Redis server v=5.0.5 sha=00000000:0 malloc=libc bits=64 build=41e6f0ceeb93db87
[root@applehubvm redis-cluster]#

每个配置文件的主要修改的内容为:（ip都是127.0.0.1）


port 7001
cluster-enabled yes 
cluster-config-file nodes-7001.conf 
cluster-node-timeout 5000 
appendonly yes

编辑好之后，拷贝出6份，改下端口即可


[root@applehubvm redis-cluster]# vi 7001/redis-7001.conf 
[root@applehubvm redis-cluster]# cp -f /usr/local/redis/redis-cluster/7001/redis-7001.conf /usr/local/redis/redis-cluster/7002/redis-7002.conf
[root@applehubvm redis-cluster]# cp -f /usr/local/redis/redis-cluster/7001/redis-7001.conf /usr/local/redis/redis-cluster/7003/redis-7003.conf
[root@applehubvm redis-cluster]# cp -f /usr/local/redis/redis-cluster/7001/redis-7001.conf /usr/local/redis/redis-cluster/7004/redis-7004.conf
[root@applehubvm redis-cluster]# cp -f /usr/local/redis/redis-cluster/7001/redis-7001.conf /usr/local/redis/redis-cluster/7005/redis-7005.conf
[root@applehubvm redis-cluster]# cp -f /usr/local/redis/redis-cluster/7001/redis-7001.conf /usr/local/redis/redis-cluster/7006/redis-7006.conf
[root@applehubvm redis-cluster]#

改完之后，直观的看下，文件如下


[root@applehubvm redis-cluster]# tree -a
.
├── 7001
│   └── redis-7001.conf
├── 7002
│   └── redis-7002.conf
├── 7003
│   └── redis-7003.conf
├── 7004
│   └── redis-7004.conf
├── 7005
│   └── redis-7005.conf
└── 7006
    └── redis-7006.conf
 
6 directories, 6 files

二、安装ruby

redis集群的命令工具redis-trib可以让我们创建集群变得非常简单。redis-trib是一个用ruby写的脚本，用于给各节点发指令创建集群、检查集群状态或给集群重新分片等。 redis-trib在Redis源码的src目录下，需要gem redis来运行redis-trib。


# 安装ruby环境 
# yum install rubygems -y 
1.安装curl sudo yum install curl 
2. 安装RVM curl -L get.rvm.io | bash -s stable 
3. source /usr/local/rvm/scripts/rvm 
4. 查看rvm库中已知的ruby版本 rvm list known 
5. 安装一个ruby版本 rvm install 2.3.3 
6. 使用一个ruby版本 rvm use 2.3.3 
7. 设置默认版本 rvm remove 2.0.0 
8. 卸载一个已知版本 ruby --version 
9. 再安装redis就可以了 gem install redis

三、启动6个实例


[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7001/redis-7001.conf
46322:C 30 Jul 2020 09:48:20.598 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46322:C 30 Jul 2020 09:48:20.598 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46322, just started
46322:C 30 Jul 2020 09:48:20.598 # Configuration loaded
[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7002/redis-7002.conf 
46334:C 30 Jul 2020 09:48:29.413 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46334:C 30 Jul 2020 09:48:29.413 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46334, just started
46334:C 30 Jul 2020 09:48:29.413 # Configuration loaded
[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7003/redis-7003.conf 
46343:C 30 Jul 2020 09:48:34.343 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46343:C 30 Jul 2020 09:48:34.343 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46343, just started
46343:C 30 Jul 2020 09:48:34.343 # Configuration loaded
[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7004/redis-7004.conf 
46352:C 30 Jul 2020 09:48:38.828 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46352:C 30 Jul 2020 09:48:38.828 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46352, just started
46352:C 30 Jul 2020 09:48:38.828 # Configuration loaded
[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7005/redis-7005.conf 
46360:C 30 Jul 2020 09:48:42.717 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46360:C 30 Jul 2020 09:48:42.717 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46360, just started
46360:C 30 Jul 2020 09:48:42.717 # Configuration loaded
[root@applehubvm redis-cluster]# redis-server /usr/local/redis/redis-cluster/7006/redis-7006.conf 
46368:C 30 Jul 2020 09:48:47.172 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
46368:C 30 Jul 2020 09:48:47.172 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=46368, just started
46368:C 30 Jul 2020 09:48:47.172 # Configuration loaded

如上表示启动成功

四、创建集群

一条命令即可，

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1


[root@applehubvm redis-cluster]# redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
Adding replica 127.0.0.1:7006 to 127.0.0.1:7002
Adding replica 127.0.0.1:7004 to 127.0.0.1:7003
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: b23a63cf09c5cdd42e67220d54f9eb7478e84d24 127.0.0.1:7001
   slots:[0-5460] (5461 slots) master
M: c4d2768b42838a24063e0ebcada0180d5dcdac2f 127.0.0.1:7002
   slots:[5461-10922] (5462 slots) master
M: 259ba247ba34c9084806c5e6cbea8a16d53e9e8c 127.0.0.1:7003
   slots:[10923-16383] (5461 slots) master
S: ab432d9d7a9f6d7e7cedf7002fd442f90f5b6a6a 127.0.0.1:7004
   replicates b23a63cf09c5cdd42e67220d54f9eb7478e84d24
S: 95e5ad3503dba29dc5274334bb7a9a3b060f3051 127.0.0.1:7005
   replicates c4d2768b42838a24063e0ebcada0180d5dcdac2f
S: 36e8e1864361b5636b178ddd28164afbaab48147 127.0.0.1:7006
   replicates 259ba247ba34c9084806c5e6cbea8a16d53e9e8c
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
..
>>> Performing Cluster Check (using node 127.0.0.1:7001)
M: b23a63cf09c5cdd42e67220d54f9eb7478e84d24 127.0.0.1:7001
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 259ba247ba34c9084806c5e6cbea8a16d53e9e8c 127.0.0.1:7003
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: 95e5ad3503dba29dc5274334bb7a9a3b060f3051 127.0.0.1:7005
   slots: (0 slots) slave
   replicates c4d2768b42838a24063e0ebcada0180d5dcdac2f
M: c4d2768b42838a24063e0ebcada0180d5dcdac2f 127.0.0.1:7002
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 36e8e1864361b5636b178ddd28164afbaab48147 127.0.0.1:7006
   slots: (0 slots) slave
   replicates 259ba247ba34c9084806c5e6cbea8a16d53e9e8c
S: ab432d9d7a9f6d7e7cedf7002fd442f90f5b6a6a 127.0.0.1:7004
   slots: (0 slots) slave
   replicates b23a63cf09c5cdd42e67220d54f9eb7478e84d24
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@applehubvm redis-cluster]#

出现以上提示，即表示创建成功。从日志中可以很清晰的得出以下集群拓扑结构：

五、测试验证

注意加 -c 参数表示以集群方式连接


[root@applehubvm bin]# redis-cli -c -p 7001
127.0.0.1:7001> set name applehub
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK
127.0.0.1:7002>

很明显，"name"经过CRC16算法之后，所匹配到的哈希槽位落到了7002机器（端口）上，所以会从7001自动跳转到7002上去。如果在7002上get name，是能拿到值的。


[root@applehubvm bin]# clear
[root@applehubvm bin]# redis-cli -c -p 7001
127.0.0.1:7001> set name applehub
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK
127.0.0.1:7002> get name
"applehub"
127.0.0.1:7002>

按照集群拓扑图，7005是7002的从节点，但是槽位分配是空，所以在7005上获取name，是会跳转到7002上的，如下：


[root@applehubvm ~]# redis-cli -c -p 7005
127.0.0.1:7005> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
"applehub"
127.0.0.1:7002>

查看下当前集群节点信息：


127.0.0.1:7002> cluster nodes
b23a63cf09c5cdd42e67220d54f9eb7478e84d24 127.0.0.1:7001@17001 master - 0 1596077244177 1 connected 0-5460
95e5ad3503dba29dc5274334bb7a9a3b060f3051 127.0.0.1:7005@17005 slave c4d2768b42838a24063e0ebcada0180d5dcdac2f 0 1596077242000 8 connected
36e8e1864361b5636b178ddd28164afbaab48147 127.0.0.1:7006@17006 slave 259ba247ba34c9084806c5e6cbea8a16d53e9e8c 0 1596077242166 3 connected
259ba247ba34c9084806c5e6cbea8a16d53e9e8c 127.0.0.1:7003@17003 master - 0 1596077241160 3 connected 10923-16383
ab432d9d7a9f6d7e7cedf7002fd442f90f5b6a6a 127.0.0.1:7004@17004 slave b23a63cf09c5cdd42e67220d54f9eb7478e84d24 0 1596077243172 4 connected
c4d2768b42838a24063e0ebcada0180d5dcdac2f 127.0.0.1:7002@17002 myself,master - 0 1596077243000 8 connected 5461-10922

此时，假如把7002宕机，注意在宕机之前，7002上的槽位是5461-10922，记住这个槽位信息


[root@applehubvm redis-cluster]# ps -aux | grep red
root      46323  0.1  0.1 145820  3068 ?        Ssl  09:48   0:05 redis-server 127.0.0.1:7001 [cluster]
root      46344  0.1  0.1 146080  3220 ?        Ssl  09:48   0:05 redis-server 127.0.0.1:7003 [cluster]
root      46353  0.1  0.1 145792  2968 ?        Ssl  09:48   0:05 redis-server 127.0.0.1:7004 [cluster]
root      46369  0.1  0.1 145792  2936 ?        Ssl  09:48   0:04 redis-server 127.0.0.1:7006 [cluster]
root      48969  0.1  0.2 149108  5392 ?        Ssl  10:41   0:00 redis-server 127.0.0.1:7002 [cluster]
root      49264  0.1  0.3 148976  7016 ?        Ssl  10:47   0:00 redis-server 127.0.0.1:7005 [cluster]
root      49277  0.0  0.0  14076  1204 pts/2    S+   10:47   0:00 redis-cli -c -p 7005
root      49422  0.0  0.0 112828   976 pts/0    S+   10:50   0:00 grep --color=auto red
[root@applehubvm redis-cluster]# kill -9 48969
[root@applehubvm redis-cluster]#

再来7005上看下name能不能拿到


[root@applehubvm bin]# redis-cli -c -p 7005
127.0.0.1:7005> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
Could not connect to Redis at 127.0.0.1:7002: Connection refused
Could not connect to Redis at 127.0.0.1:7002: Connection refused
not connected> 
[root@applehubvm bin]# redis-cli -c -p 7005
127.0.0.1:7005> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
Could not connect to Redis at 127.0.0.1:7002: Connection refused
Could not connect to Redis at 127.0.0.1:7002: Connection refused
not connected> get name
Could not connect to Redis at 127.0.0.1:7002: Connection refused
not connected>  
[root@applehubvm bin]# redis-cli -c -p 7005
127.0.0.1:7005> get name
"applehub"
127.0.0.1:7005>

刚开始的时候，还是会跳转到7002上去拿，发现连不上，后面再多拿几次，发现不再跳转到7002上，而是直接在7005自己这取，说明此时，已经完成了槽位的迁移和fail over。由于7002的宕机，自动切换到7005上提供服务。再看下节点信息，可以发现7002已经宕机，并且，7005的槽位是5461-10922，刚好就是7002宕机之前的槽位。


127.0.0.1:7005> cluster nodes
95e5ad3503dba29dc5274334bb7a9a3b060f3051 127.0.0.1:7005@17005 myself,master - 0 1596077806000 9 connected 5461-10922
c4d2768b42838a24063e0ebcada0180d5dcdac2f 127.0.0.1:7002@17002 master,fail - 1596077530444 1596077529033 8 disconnected
259ba247ba34c9084806c5e6cbea8a16d53e9e8c 127.0.0.1:7003@17003 master - 0 1596077807000 3 connected 10923-16383
ab432d9d7a9f6d7e7cedf7002fd442f90f5b6a6a 127.0.0.1:7004@17004 slave b23a63cf09c5cdd42e67220d54f9eb7478e84d24 0 1596077807587 4 connected
b23a63cf09c5cdd42e67220d54f9eb7478e84d24 127.0.0.1:7001@17001 master - 0 1596077806000 1 connected 0-5460
36e8e1864361b5636b178ddd28164afbaab48147 127.0.0.1:7006@17006 slave 259ba247ba34c9084806c5e6cbea8a16d53e9e8c 0 1596077806578 6 connected
127.0.0.1:7005>

再次启动7002,去拿name


redis-server /usr/local/redis/redis-cluster/7002/redis-7002.conf
 
 
127.0.0.1:7002> get name
"applehub"
127.0.0.1:7002> get name
-> Redirected to slot [5798] located at 127.0.0.1:7005
"applehub"
127.0.0.1:7005>

可以看到，是跳转到7005上去拿，因为此时，7002已经变成了7005的从节点。


127.0.0.1:7005> cluster nodes
95e5ad3503dba29dc5274334bb7a9a3b060f3051 127.0.0.1:7005@17005 myself,master - 0 1596078116000 9 connected 5461-10922
c4d2768b42838a24063e0ebcada0180d5dcdac2f 127.0.0.1:7002@17002 slave 95e5ad3503dba29dc5274334bb7a9a3b060f3051 0 1596078117007 9 connected
259ba247ba34c9084806c5e6cbea8a16d53e9e8c 127.0.0.1:7003@17003 master - 0 1596078118012 3 connected 10923-16383
ab432d9d7a9f6d7e7cedf7002fd442f90f5b6a6a 127.0.0.1:7004@17004 slave b23a63cf09c5cdd42e67220d54f9eb7478e84d24 0 1596078117000 4 connected
b23a63cf09c5cdd42e67220d54f9eb7478e84d24 127.0.0.1:7001@17001 master - 0 1596078116000 1 connected 0-5460
36e8e1864361b5636b178ddd28164afbaab48147 127.0.0.1:7006@17006 slave 259ba247ba34c9084806c5e6cbea8a16d53e9e8c 0 1596078119016 6 connected
127.0.0.1:7005>

以上过程，完整演示了7001到7006,6台机器组成的cluster集群，从搭建到故障转移，槽位的自动迁移，主从切换等过程。对理解redis cluster集群有帮助。建议不要使用脚本，使用这种手写命令的形式，会理解的更加深刻。下一次，讲一下redis的底层的知识吧，比如之前的单线程模型、文件事件处理器、epoll那些。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/683669