1.集群是什么？
在Redis早期的时候，经常会出现容量不够的问题，这也就联想到：redis如何进行扩容？并发写操作， redis如何分摊？
另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。
之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。
Redis集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。
2.Redis集群的搭建
首先需要删除各台redis服务器的持久化数据（rdb、aof文件）。使用 rm -rf 命令。
在这里本应该打开6台linux虚拟机，但是考虑到电脑性能问题，我就在同一台linux虚拟机中，构造6台redis服务器，用来模拟集群操作。
制作6个实例，6379,6380,6381,6389,6390,6391 分别是相应的端口号。
在这6台redis服务器的配置文件中配置如下内容：👇👇👇（这里只给出6379的配置，其他5台，把6379改为对应的端口号就可以了。快速修改使用:%s/6379/6380）
cluster-enabledyes 打开集群模式
cluster-config-filenodes-6379.conf 设定节点配置文件名
cluster-node-timeout15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。
下来，依次启动这6台redis服务器。
将六个redis节点合成一个redis集群。组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。
这行命令中的ip地址最好不要用127.0.0.1，请用真实IP地址。（因为这里只做模拟，所以是在同一台linux主机上，可以写127.0.0.1。但是未来在企业里肯定是多台linux，ip地址都是不一样的。）
--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。
集群合成之后，在最后有这样一行代码：[OK] All 16384 slots covered.
一个 Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这 16384 个插槽的其中一个，
集群使用公式CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。
集群中的每个节点负责处理一部分插槽。举个例子，如果一个集群可以有主节点，其中：
节点 6379 负责处理 0 号至 5460 号插槽。
节点 6380 负责处理 5461 号至 10922 号插槽。
节点 6381 负责处理 10923 号至 16383 号插槽。
我们使用redis -c -p 6379 （ -c 采用集群策略连接，设置数据会自动切换到相应的写主机）进入6379这台redis服务器中，使用 cluster nodes 查看一下集群中的节点信息。一个集群至少要有三个主节点。
可以看到，上面截图中的命令--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。
也就是：6379和6389是一组（6379为主，6389为从）；6380和6390是一组（6380为主，6390为从）；6381和6391是一组（6381为主，6391为从）。
下面，我们在6379这台redis服务器中，向其中写入数据。
可能直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群方式登录。
在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
redis-cli客户端提供了–c 参数实现自动重定向。
如redis-cli -c–p 6379登入后，再录入、查询键值对可以自动重定向。
关于mset命令报错：不在一个slot下的键值，是不能使用mget,mset等多键操作。
关于mset命令报错解决：可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。
查询集群中的值：CLUSTER GETKEYSINSLOT <slot><count> 返回 count 个 slot 槽中的键。
3.Redis集群故障恢复
如果主节点下线？从节点能否自动升为主节点？注意：15秒超时
这里，我们让6379这台主服务器宕机，将它shutdown。
之后再次使用 cluster nodes 查看集群中的节点信息：可以看到6379已经挂掉了，而原本它的从服务器6389，此时已经转为了主服务器。
主节点恢复后，主从关系会如何？主节点回来变成从机。
我们再次启动6379这台服务器，可以看到重启之后，6379自动成为了6389的从服务器。
如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage为yes ，那么，整个集群都挂掉
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage为no ，那么，该插槽数据全都不能使用，也无法存储。
redis.conf中的参数 cluster-require-full-coverage
