引言：
从Redis高可用方案中的—主多从架构中我们可以了解到redis主从复制架构，知道了该模式的工作模式为提供多台redis服务，选择其中的一台作为master节点向外提供读写服务，剩下的作为slave节点从master节点复制数据，只向外提供读服务。并且在Redis高可用架构—哨兵（sentinel）机制详细介绍中引入了Redis哨兵，实现了对所有redis节点的监控和master的自动故障转移。一般情况下来说，上面两种方式结合起来使用已经可以满足大部分的redis高可用场景，但它有一个很明显的缺点：只有一台master节点向外提供写服务，其他的slave节点只能提供读服务。所以，当写操作并发量很大的，无法缓解写操作的压力。针对这种场景，Redis在3.0版本中引入了Redis集群的部署架构。
一、Redis集群的概念
Redis集群是一个提供在多个Redis节点之间共享数据的程序集。它并不像Redis主从复制模式那样只提供一个master节点提供写服务，而是会提供多个master节点提供写服务，每个master节点中存储的数据都不一样，这些数据通过数据分片的方式被自动分割到不同的master节点上。为了保证集群的高可用，每个master节点下面还需要添加至少1个slave节点，这样当某个master节点发生故障后，可以从它的slave节点中选举一个作为新的master节点继续提供服务。
二、Redis集群的搭建过程（centos7环境）
在根目录创建一个jqredis文件夹用来存放redis集群的相关文件
进入我们的redis的安装位置，将redis.conf复制到jqredis文件夹下，因为我在主从架构的搭建时已经将其引入到根目录下的myredis文件夹下了，所以在下面步骤的公共部分的引入是引入了myredis文件夹下的redis.conf
?进入jqredis文件夹，通过 vi redis6379.conf自己创建一个redis6379.conf文件，输入以下内容：
include /myredis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
其中
port 6379表示端口号
dbfilename "dump6379.rdb"表示持久化文件名
cluster-enabled yes表示开启集群方式
cluster-config-file nodes-6379.conf表示设置节点配置文件名
cluster-node-timeout 15000表示设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换
include /myredis/redis.conf表示引入我们从redis安装目录复制的redis.conf作为公共文件，如果按照上面步骤将redis.conf复制到了jqredis文件夹，则需将include /myredis/redis.conf改为include /jqredis/redis.conf
重复上述操作，创建redis6380.conf，redis6381.conf，redis6389.conf，redis6390.conf，redis6391.conf，并输入上述内容保存，记得改端口号，可通过：%s/6379/6380命令将该conf下的所有6379变成6380，如redis6380.conf内容如下：
创建完所有的conf文件，修改完所有的端口号，有如下文件
启动这6个不同端口号的redis-server
查看redis进程
?此时进入jqredis文件夹查看，可以发现生成了节点的配置文件
进入redis安装目录redis-6.0.6的src目录下
确保所有的redis实例启动后，node-xxxx.conf文件都生成正常，进入redis-6.0.6的src目录下之后，将6个节点合成一个集群，命令为：redis-cli --cluster create --cluster-replicas 1 192.168.0.110:6379 192.168.0.110:6380 192.168.0.110:6381 192.168.0.110:6389 192.168.0.110:6390 192.168.0.110:6391
其中redis-cli --cluster create --cluster-replicas 1中的1表示采用简单的方式配置集群，一台主机，一台从机，正好3组。
192.168.0.110:6379则是表示ip地址与端口号，由于此次集群在虚拟机的一个centos7系统下搭建，因此ip地址都是一样的，但在实际开发中，redis实例都是放在不同服务器上的，因此ip地址会不一样，这样也才能真正体现出集群的作用。
输入上述命令后会将6379，6380，6381作为主服务器，6389作为6379的从服务器，6390作为6380的从服务器，6391作为6381的从服务器，
输入yes同意对这六个redis实例在集群中的分配
如下图，出现all 16384 slots covered表示16384个插槽在集群中的3个主节点分配完毕，集群在这里也算搭建完成了。
三、redis集群的客户端的启动
通过redis-cli -c -p 6379启动集群的客户端，这里注意，无论是使用了6个redis实例中的哪个端口号都可以启动。启动后，我们也可以从启动后的信息查看到集群中主节点和从节点的分配情况。
四、集群中插槽的分配
一个Redis集群包含16384个插槽(hashslot)，数据库中的每个键都属于这16384个插槽的其中一个，集群使用公式CRC16(key)%16384 来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和。集群中的每个主节点负责处理一部分插槽。举个例子，如果一个集群可以有主节点，就例如上章redis集群客户端的启动的截图:
从该截图中，我们可以知道：
主节点6379负责处理0号至5460号插槽。
主节点6380负责处理5461号至10922号插槽。
主节点6381负责处理10923号至16383号插槽。
五、集群的测试
设置键值对k1的值为v1，此时可以发现k1在插槽12706的位置，因此写在了6381的主节点上。再设置k2，值为v2。可以发现k2的插槽位置为449，被分配到6379的主节点上。
?接着，我们在6380端口号的客户端通过cluster keyslot k1命令来获取k1的插槽位置为12706，并且通过这个插槽的位置12706来查看该插槽是否有值，结果如图所示，结果为：（integer）0，这是因为该插槽被分配给了6381端口号的主节点，因此，6380端口号主节点不能查找到k1的。
我们在刚刚设置k2时，可以知道k2的插槽位置为449，在主节点6379上，因此，在6379客户端来查看449插槽是否有值应该是可行的，接下来，我们测试一下，如下图：
通过上图可知，我们的猜想正确。
接下来，我们来测试一下当集群中的主机宕机了，该宕机的主主节点的从节点会不会成为新的主节点。我们用shutdown来模拟宕机。
?启动集群中的另一端口号，来查看集群中主从的情况
从上图中，我们可以发现6379主节点已经fail，原本为6379主节点的从节点6389变为主节点。
当我们再次启动6379节点时，我们可以发现6379节点已经变为了6389节点的从节点，如下图：
测试总结：
1、没有分配到该插槽的主从节点不能获取到该插槽的值，但所有节点均能通过设置的键值对的名称获取到该插槽的位置。
2、当集群中的主从结构的主节点宕机，从节点会切换为主节点。
延申：
当集群中的同一主从结构的主从节点都宕机了，这时整个集群会不会挂掉？
其实，这个问题是通过设置的参数cluster-require-full-coverage来决定:
当luster-require-full-coverage为yes，那么整个集群都将挂掉。
当luster-require-full-coverage为no，那么该主从结构分配到插槽全部无法使用。