Redis进阶-Redis集群 【高可用切换】&【cluster-require-full-coverage】集群是否完整才能对外提供服务

---

Pre

Redis进阶-Redis集群原理剖析及gossip协议初探 中提到了 “ 集群是否完整才能对外提供服务” ，这里我们详细展开验证下

---

需求 ：集群不完整仍然需要对外提供服务

假设我们现在的集群架构是 3主 6从 的redis cluster .

那3个master 平分16384个slot，每个master的小集群 负责 1/3的slot，对应一部分数据。

通常情况，如果这3个小集群中，任何一个（1主2从） 挂了，你这个集群对外可提供的数据只有2/3了， 整个集群是不完整的， redis 默认在这种情况下，是不会对外提供服务的。

如果你的诉求是，集群不完整的话 也需要对外提供服务，比如如下，你也希望redis cluster 对外提供服务

Redis也考虑到了这一点，提供了参数cluster-require-full-coverage

cluster-require-full-coverage： 默认值 yes , 即需要集群完整性，方可对外提供服务 ,

如果你要支持上述你的需求，需要将该参数设置为no ，这样的话，你挂了的那个小集群是不行了，但是其他的小集群仍然可以对外提供服务。

redis.conf中说明和配置如下：

---

验证

Redis Cluster 架构

我们先看下默认参数下的场景 ， 先看下我们目前的redis nodes 情况 （简单的3主3从）

[redis@artisan bin]$ ./redis-cli -c -h 192.168.18.131 -p 8001 -a artisan
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.18.131:8001> CLUSTER NODES
3410ea1dd49144f5d02b59036641bde566f03ee0 192.168.18.132:8005@18005 master - 0 1586809003000 10 connected 10923-16383
9a6804a96f9351d3fd61ea1e4d7dd77976b4133b 192.168.18.132:8002@18002 master - 0 1586809002648 3 connected 5461-10922
c4083f856388cc73feb3223433d10500b5556abe 192.168.18.131:8004@18004 slave 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b 0 1586809002547 3 connected
6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 192.168.18.131:8001@18001 myself,master - 0 1586809001000 9 connected 0-5460
80618eaa0de9524cf439294b7cb6df1a34d3ad22 192.168.18.133:8003@18003 slave 3410ea1dd49144f5d02b59036641bde566f03ee0 0 1586809003961 10 connected
3178d965b77e2967930d7ea6072cdb9d7e5ba8ef 192.168.18.133:8006@18006 slave 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 0 1586809003000 9 connected
192.168.18.131:8001> 

192.168.18.131:8001主 192.168.18.133:8006从

192.168.18.132:8005 主 192.168.18.133:8003 从

192.168.18.132:8002 主 192.168.18.131:8004从

高可用切换

手工kill 8001 ，模拟故障

[redis@artisan redis-5.0.3]$ cd bin/
[redis@artisan bin]$ ps -ef|grep redis-server
redis       655    597  0 06:06 pts/1    00:00:00 grep --color=auto redis-server
redis      2926      1  0 Apr12 ?        00:09:43 ./redis-5.0.3/bin/redis-server *:8001 [cluster]
redis      2949      1  0 Apr12 ?        00:10:00 ./redis-5.0.3/bin/redis-server *:8004 [cluster]
[redis@artisan bin]$ 
[redis@artisan bin]$ 
[redis@artisan bin]$ 
[redis@artisan bin]$ kill 2926
[redis@artisan bin]$ 

先看看他的从节点 8006的日志 ，仔细观察日志

7834:S 14 Apr 2020 06:06:19.665 # Connection with master lost.
7834:S 14 Apr 2020 06:06:19.665 * Caching the disconnected master state.
7834:S 14 Apr 2020 06:06:19.804 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:19.804 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:19.804 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:20.812 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:20.812 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:20.813 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:21.822 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:21.822 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:21.822 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:22.831 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:22.832 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:22.833 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:23.843 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:23.844 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:23.844 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:24.849 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:24.849 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:24.849 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:25.858 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:25.858 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:25.858 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:26.542 * FAIL message received from 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b about 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1
7834:S 14 Apr 2020 06:06:26.542 # Cluster state changed: fail
7834:S 14 Apr 2020 06:06:26.567 # Start of election delayed for 663 milliseconds (rank #0, offset 211176).
7834:S 14 Apr 2020 06:06:26.869 * Connecting to MASTER 192.168.18.131:8001
7834:S 14 Apr 2020 06:06:26.869 * MASTER <-> REPLICA sync started
7834:S 14 Apr 2020 06:06:26.869 # Error condition on socket for SYNC: Connection refused
7834:S 14 Apr 2020 06:06:27.273 # Starting a failover election for epoch 15.
7834:S 14 Apr 2020 06:06:27.309 # Failover election won: I'm the new master.
7834:S 14 Apr 2020 06:06:27.309 # configEpoch set to 15 after successful failover
7834:M 14 Apr 2020 06:06:27.309 # Setting secondary replication ID to eb9734612ef543cff912182e38ad59e531770939, valid up to offset: 211177. New replication ID is 7dc4e4f8a55df7feac1dc7979ea7a783bad2d2e4
7834:M 14 Apr 2020 06:06:27.309 * Discarding previously cached master state.
7834:M 14 Apr 2020 06:06:27.309 # Cluster state changed: ok

看看8005（两位一个主节点）

6926:M 14 Apr 2020 06:06:26.540 * Marking node 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 as failing (quorum reached).
6926:M 14 Apr 2020 06:06:26.540 # Cluster state changed: fail
6926:M 14 Apr 2020 06:06:27.305 # Failover auth granted to 3178d965b77e2967930d7ea6072cdb9d7e5ba8ef for epoch 15
6926:M 14 Apr 2020 06:06:27.310 # Cluster state changed: ok

granted to 3178d965b77e2967930d7ea6072cdb9d7e5ba8ef （8006的NodeID） ， 主节点回应

再看看 8003 （8005的从节点）

7826:S 14 Apr 2020 06:06:26.543 * FAIL message received from 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b about 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1
7826:S 14 Apr 2020 06:06:26.543 # Cluster state changed: fail
7826:S 14 Apr 2020 06:06:27.344 # Cluster state changed: ok

从节点不回应

符合我们之前说的集群选举过程。

---

查看集群状态

可以发现 8006 提升为了主节点 ，8001的状态为fail

---

Code访问测试

import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.JedisPoolConfig;

import java.io.IOException;
import java.util.HashSet;
import java.util.Set;


public class JedisClusterDemo {
    public static void main(String[] args) throws IOException {

        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(20);
        config.setMaxIdle(10);
        config.setMinIdle(5);

        Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();
        jedisClusterNode.add(new HostAndPort("192.168.18.131", 8001));
        jedisClusterNode.add(new HostAndPort("192.168.18.131", 8004));
        jedisClusterNode.add(new HostAndPort("192.168.18.132", 8002));
        jedisClusterNode.add(new HostAndPort("192.168.18.132", 8005));
        jedisClusterNode.add(new HostAndPort("192.168.18.133", 8003));
        jedisClusterNode.add(new HostAndPort("192.168.18.133", 8006));

        JedisCluster jedisCluster = null;
        try {
            //connectionTimeout：指的是连接一个url的连接等待时间
            //soTimeout：指的是连接上一个url，获取response的返回等待时间
            jedisCluster = new JedisCluster(jedisClusterNode, 6000, 5000, 10, "artisan", config);
            System.out.println(jedisCluster.set("clusterArtisan", "artisanValue"));
            System.out.println(jedisCluster.get("clusterArtisan"));
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedisCluster != null)
                jedisCluster.close();
        }
    }
}

---

继续停掉8006 ，验证集群是否down掉

[redis@artisan log]$ ps -ef|grep 8006
redis      6371   3391  0 06:21 pts/0    00:00:00 grep --color=auto 8006
redis      7834      1  0 Apr12 ?        00:09:30 ./redis-5.0.3/bin/redis-server *:8006 [cluster]
[redis@artisan log]$ 
[redis@artisan log]$ 
[redis@artisan log]$ kill 7834
[redis@artisan log]$ 
[redis@artisan log]$ 

再次使用代码访问 ，CLUSTERDOWN The cluster is down

结果。。集群宕了。 默认情况下 cluster-require-full-coverage 为 yes ，需要集群完整性，才能对外提供服务

在查看下nodes的状态

如果你想这个时候，还让redis对外提供服务，cluster-require-full-coverage设置为no 即可。

已经验证过了，未记录笔记，周知~