一文道明Redis集群架构工作原理及搭建

---

前言

今天和大家分享一下Redis真正意义上的一种高可用架构，就是Redis-Cluster（Redis集群）。它具有复制、高可用和分片的特性。他可以完全不用sentinel哨兵也能实现节点删除和故障转移的功能。并且当主节点挂掉以后新选举主节点的速度也比sentinel快。当然，他的主节点可以有很多个。官方提供的数据是最多可以有10000个，但是官方也建议最好不要超过1000个，否则会影响Redis的性能。这也为什么说Redis-Cluster是真正意义上实现了高可用。今天主要分两个部分分享，一是分享Redis-Cluster如何搭建。二是Redis-Cluster的工作原理以及相关问题作出解释。

一、Redis-Cluster(集群)长什么样子？

我还是通过一张图作出解释：

从结构图上可以看出Redis-Cluster明显不同于和主从架构和哨兵架构。Redis集群里面可以看到他有好多个主节点。Redis集群至少需要三个主节点。后面我会解释为什么至少需要三个主节点。通过这幅图重点去理解复制、高可用和分片。复制就是说我们的主从节点可以横向扩展。建议不要超过1000个。高可用是相比哨兵架构模式，在哨兵架构模式下虽然能做到故障转移但是不能用于并发特别高的场景中，因为只有一个主节点。而集群模式下他可以有很多个主节点对客户端提供服务。分片就是分片存储。用户在set一个key的时候，服务端拿到这个key会做哈希槽定位算法，把这个key所对应的值 存放到对应的哈希槽中。所以他是分片的。后面还会详细说明哈希槽定位算法。

---

二、Redis-Cluster集群搭建

1. Redis集群搭建

搭建图我已经在上面提供了。不过这里需要申明一下，我们我也是在虚拟机上搭建的。计算机本身硬件条件有限，所有我就创建了三台虚拟机，分别是vm-server1、vm-server2和vm-server3。在每一台虚拟机机器上分别搭建一个主节点和两个从节点。是不是有很多疑惑，一台机器可以安装多个Redis实例。怎么安装？很简单。我们只需要提前把Redis安装好（按照在一台机器上安装Redis的方式安装就ok了），接下来我们只需要把redis安装根目录下面的redis.conf文件复制多分，配置对应的redis.config文件，然后启动的时候指定对应的配置文件即可。那我们就开始安装吧

为了整体结构清晰，我就不在redis的根目录下操作了。我在 /usr/local 目录下面新建一个redis-cluster文件夹，存放对应节点的redis配置文件
[root@192 local]# mkdir redis-cluster

# vm-server1配置主节点和从节点
在vm-serever1的redis-cluster文件下面新建三个目录7000、7001和7002。7000目录用来存放master节点的redis配置文件,7001和7002分别存放从节点的redis配置文件。
创建三个文件夹命令如下：
[root@192 redis-cluster]# mkdir 7000 7001 7002
分别将redis.config文件复制到这三个文件夹中
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7000/
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7001/
[root@192 redis-cluster]# cp ../redis-5.0.14/redis.conf 7002/

#进入7000目录下面的redis.config文件进行配置：
[root@192 redis-cluster]# vim 7000/redis.conf
#接下来就正式开始配置了，前面的都是辅助工作：
1、daemonize yes  //开启后台启动
2、port 7000	  //修改端口（如果在一台机器上开启多个redis实例，就需要为每个redis实例配置不同的端口号）
3、pidfile /var/run/redis_7000.pid   //把pid进程号写入pidfile配置的文件
4、dir /usr/local/redis-cluster/7000/   //指定数据文件的存放位置，必须指定存放在不同的目录中，否则会丢失数据
5、cluster-enabled yes   //开启集群模式
6、cluster-config-file nodes-7000.conf  //集群节点信息文件，建议最好与port一致
7、cluster-node-timeout 10000     //集群节点的超时时间（超过这个时间，集群中的其他主节点就认为这个挂了）
8、#bind 127.0.0.1    //bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可
9、protected-mode no  //关闭保护模式
10、appendonly yes   //开启aof持久化

#如果需要配置密码（可以不配置）
11、requirepass root  //设置访问redis的密码
12、masterauth root  //设置集群节点间访问密码

#其他节点也是这样配置，只是上面设计到端口号的需要改变一下。为了方便期间，我们直接把刚才配置号的配置文件分别复制到7001和7002里面（其他机器也是这样配置，改端口就行）。
#下面我列举一下具体改那些端口号：
1、port:xxxx   //修改对应的端口号   7000 7001 7002 8000 8001等
2、pidfile /var/run/redis_xxxx.pid  //修改对应的端口号 7000 7001 7002 8000 8001等
3、dir /usr/local/redis-cluster/xxxx/  //修改成对应端口号 7000 7001 7002 8000 8001等
4、cluster-config-file nodes-xxxx.conf   //修改i成对应端口号 7000 7001 7002 8000 8001等
配置就完成了

启动如下命令如下（启动vm-server1机器的redis实例）：
redis-5.0.14/src/redis-server redis-cluster/7000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/7001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/7002/redis.conf

启动如下命令如下（启动vm-server2机器的redis实例）：
redis-5.0.14/src/redis-server redis-cluster/8000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/8001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/8002/redis.conf

启动如下命令如下（启动vm-server3机器的redis实例）：
redis-5.0.14/src/redis-server redis-cluster/9000/redis.conf
redis-5.0.14/src/redis-server redis-cluster/9001/redis.conf
redis-5.0.14/src/redis-server redis-cluster/9002/redis.conf

以上就完成了所有主从redis节点的启动。但是，他们彼此之间都是游离的状态，还没有组成集群。我们只是以集群的方式启动了。好，接下来我们就配置他们成为集群。我们使用redis-cli创建redis集群（redis5以前是使用ruby脚本redis-trib.rb实现）配置之前，记得关闭机器的防火墙，否则，节点之间没发通信。要不就将节点的所有端口都加入到防火墙中（所有端口包括redis服务端口和集群节点gossip通信端口16739，集群端口默认是在redis端口上加上1万）。

systemctl status firewalld.service #查看防火墙状态
systemctl stop firewalld # 临时关闭防火墙
systemctl disable firewalld # 禁止开机启动

生成集群的命令如下（我们只需要在三台机器上任意一台机器运行这段命令即可）：

redis-5.0.14/src/redis-cli -a root --cluster create --cluster-replicas 2 192.168.1.7:7000 192.168.1.8:8000 192.168.1.9:9000 192.16168.1.7:7001 192.168.1.7:7002 192.168.1.8:8001 192.168.1.8:8002 192.168.1.9:9001 192.168.1.9:9002

详细解释如下图

集群创建成功如下图：

接下来我们验证一下集群是否搭建成功。连接任意一个客户端 redis-5.0.14/src/redis-cli -a -c -h -p(-a 访问redis服务端密码，-c 表示集群模式、-h 指定IP地址、-p 端口号)
例如：redis-5.0.14/src/redis-cli -a root -c -h 192.168.1.8 -p 8000

进如以后，可以使用cluster info查看集群信息以及使用cluster nodes查看节点信息
使用cluster info 命令查看节点信息如下图：

使用cluster nodes查看集群节点信息如下图所示：

不知道大家使用cluster nodes命令查看完集群的节点信息以后会不会有疑问？就是在文章最开始的时候有一个结构吴图，上面描述着每个主节点信息以及主节点对应的从节点信息。例如：7000端口的主节点对应的从节点按照架构图上的描述应该是7001和7002机器。但是，根据cluster nodes命令查看结果来看，好像跟我们说的还有点差别。可以看出，7000主节点对应的从节点分别是8001和9001。为什么会这样？我来解释一下，Redis在创建集群的过程中，我们可以控制让那些节点成为主节点，但是不能控制主节点对应的从节点。这个分配是随机的。其实更重要有的原因是，Redis集群认为，如果一个主节点和他的从节点都在一台机器上。如果这台机器宕机了，那么所有的主从节点都将不能使用。所以，才会分散开来。
关闭集群需要逐个去关闭，使用如下命令：
redis-5.0.14/src/redis-cli -a root -c -h 192.168.1.7 -p 7000 shutdown
在关闭集群以后再次启动redis集群时，不需要再次配置集群。只需要我们正常启动redis实例就可以。集群的配置文件已经记录了集群的配置信息，集群会根据配置信息进行内部通信调整。

2. 客户端测试

通过jedis客户端连接测试：

@SpringBootTest
class RedisTestApplicationTests {

    @Test
    void testRedisCluster() throws IOException {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(20);
        jedisPoolConfig.setMaxIdle(10);
        jedisPoolConfig.setMinIdle(5);

        Set<HostAndPort> set = new HashSet<>();
        set.add(new HostAndPort("192.168.1.7",7000));
        set.add(new HostAndPort("192.168.1.8",8000));
        set.add(new HostAndPort("192.168.1.9",9000));

        set.add(new HostAndPort("192.168.1.7",7001));
        set.add(new HostAndPort("192.168.1.7",7002));

        set.add(new HostAndPort("192.168.1.8",8001));
        set.add(new HostAndPort("192.168.1.8",8002));

        set.add(new HostAndPort("192.168.1.9",9001));
        set.add(new HostAndPort("192.168.1.9",9002));


        JedisCluster jedisCluster = null;
        try {
            jedisCluster = new JedisCluster(set,6000,5000,10,"root",jedisPoolConfig);
            jedisCluster.set("wife","duanting");
            System.out.println("jedisCluster.get(\"wife\") = " + jedisCluster.get("wife"));
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            if(jedisCluster != null){
                jedisCluster.close();
            }
        }
    }
   }

运行结果图如下：

springboot集成测试：
首先需要引入两个依赖：

		<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>

其次，需要在springboot的配置文件中配置：

server:
  port: 7500
spring:
  redis:
    database: 0  #配置redis默认的数据库
    timeout: 5000 #配置超市时间
    cluster:  #配置redis集群的所有主从节点
      nodes: 192.168.1.7:7000,192.168.1.8:8000,192.168.1.9:9000,192.168.1.7:7001,192.168.1.7:7002,192.168.1.8:8001,192.168.1.8:8002,192.168.1.9:9001,192.168.1.9:9002
    lettuce:
      #配置连接池的信息
      pool:
        max-active: 100
        max-idle: 50
        min-idle: 10
        max-wait: 1000
    password: root #配置密码

测试代码如下：

	@Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Test
    public void testSpringbootRedis() {
        int i = 1;
        while (true) {
            try {
                stringRedisTemplate.opsForValue().set("xiaohua" + i, "luxiaohua" + i);
                System.out.println("设置小花" + i);
                Thread.sleep(1000);
                i++;
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

    }

运行结果：

到这里，我们的集群基本就搭建完成了。

3. 增加主节点（6000）到集群环境中

试试想，如果在实际生产环境中，我们的集群性能可能跟不上业务的并发要求，这时候需要我们扩充性能，之前讲过，redis集群他是可以横向扩展的，所以，我们架构图变成如下图：

我们新加入了一组节点，主节点是6000，从节点分别是6001和6002。由于机器资源有限，我就将新添加的节点扩充在vm-server1机器上了。真实环境中肯定是部署在不同的机器上的。我们还是在redis-cluster目录下面新建三个文件夹，分别是6000、6001和6002。同样，将redis.config文件复制到这三个目录下面并修改对应的端口号。最后将新加入的节点redis启动起来。

分别启动三台新加入的节点redis

在将新节点加入集群之前，先来介绍几个redis命令：在redis客户端输入 --cluster help可以查看相关命令，具体如下图所示：

接下来我们使用add-node命令将端口号为6000的机器添加到集群环境中，并且是master节点。
添加命令：redis-5.0.14/src/redis-cli -a root --cluster add-node 192.168.1.7:6000 192.168.1.7:7000

接下来我们使用cluster nodes命令查看集群中有没有端口号为6000的节点：

所以，当新添加的节点成功以后，新增的节点不会有任何数据，因为之前说过，redis的集群环境中，它具有分片能力，他把JedisCluster分成了16384个槽位，然后根据槽位定位算法（hash(key)%16384）看最终定位到那个分片中。所以，此时新增加的节点还没有任何的slot(hash槽位)，所以接下来需要我们手动去分配槽位信息给新加的主节点。
使用reshard命令对新加入的主节点进行分配哈希槽。
命令：redis-5.0.14/src/redis-cli -a root --cluster reshard 192.168.1.7:6000

紧接着会输出如下信息：
How many slots do you want to move (from 1 to 16384)?
翻译：就是需要多少个哈希槽分配给这个节点，自己设置，比如2000个，就在问好后面输入2000，回车即可。

What is the receiving node ID?
翻译：把这2000个哈希槽移动到那个节点上去，需要指定节点的id(id可以使用cluster nodes命令查看)，在问号后面输入节点id,回车即可：

Please enter all the source node IDs.
Type ‘all’ to use all the nodes as source nodes for the hash slots.
Type ‘done’ once you entered all the source nodes IDs.
Source node #1:
翻译：意思就是我们需要分配的2000个节点怎么来，all是从所有的主节点（7000、8000、9000）中分别抽取相应的槽位指定到新的节点，周抽取的总槽数为2000个。这里我们在冒号后面输入all，回车即可：

Do you want to proceed with the proposed reshard plan (yes/no)?
翻译：确认 ,问好后面输入yes即可。

这就分配成功了。
再来验证一下：进入到集群中的任何一台机器，输入cluster nodes命令查看：

经过验证，我们的槽位信息已经分配成功了。

4. 添加从节点6001和6002到集群环境（6000的从节点）

还是使用添加节点的命令add-node命令来进行添加。
命令：redis-5.0.14/src/redis-cli -a root --cluster add-node 192.168.1.7:6001 192.168.1.7:6000

去集群环境中查看是否添加成功：cluster nodes

经过查看集群节点信息，我们看到6001已经加入到集群环境了，接下来我们只需要将它配置成6000的从节点。怎么配置？我们需要执行replicate命令来指定当前节点（从节点）主节点id为那个？首先需要连接新加的6001节点的客户端，然后使用集群命令进行操作。把当前节点6001指定到节点6000的从节点。

指定完成了。接下来使用集群命令查看：

好了，搞定了。使用同样的方式把6002也搞定。过程都一样。我就不演示了。

5. 删除集群中的节点

5.1 删除从节点

删除从节点6001和6002，使用del-node命令，指定删除节点ip和端口以及节点的id。
删除6001命令：
redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6001 578dd71df799ad68b692a59e1824e2058aeb4e79
删除6002命令：
redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6002 ba2fcd1b773146773c43c26e6b4642d8a8fc9448

在集群环境中在查看一下，确定是否被删除：

5.2 删除主节点

删除主节点，主节点的删除可能与从节点有点不同。因为主节点里面分配了哈希槽，所以，我们在删除主节点之前必须把主节点里面的哈希槽放入到其他可用的节点去，然后在进行移除操作，否则会出现数据丢失问题。
执行命令如下：
redis-5.0.14/src/redis-cli -a root --cluster reshard 192.168.1.7:6000

输出如下信息：
How many slots do you want to move (from 1 to 16384)?
翻译：移动多少个哈希槽位，还是当初我们分配的2000

What is the receiving node ID?
翻译：数据移动到哪里？需要移动到哪里的节点id,这里就移动到8000，暂时就不做平均分配了。
Please enter all the source node IDs.
Type ‘all’ to use all the nodes as source nodes for the hash slots.
Type ‘done’ once you entered all the source nodes IDs.
Source node #1:
翻译：这里需要我们的数据源，也就是6000节点的id

Source node #2:
翻译：这里直接输入done开始生成迁移计划

输入yes ,点击回车完成
至此，我们已经把6000的主节点的哈希槽位已经全部迁移了，接下来我们查看验证一下，看看是否迁移成功：

最后，我们直接用del-node命令删除主节点即可：
命令：redis-5.0.14/src/redis-cli -a root --cluster del-node 192.168.1.7:6000 966c98a2e30215b22d04dc907e058f487215c68e

接下来，我们在在集群环境中查看，确保删除成功：

经过验证，集群环境中已经没有6000节点了。最后，需要说明的就是，集群中的节点一旦被移除之后，他的实例也会被销毁。

看看vm-server1机器上确实只有原来的三台redis实例，新加入的三台redis实例已经销毁了。

代码如下（示例）：

三、RedisCluster（集群）原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

1、 槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。
HASH_SLOT = CRC16(key) mod 16384

2、跳转重定位

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。

3、Redis集群间的节点通信

redis cluster节点间采取gossip协议进行通信 维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip

3.1 集中式：

优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。 很多中间件都会借助zookeeper集中式存储元数据。gossip：

3.2 gossip

gossip协议包含多种消息，包括ping，pong，meet，fail等等。 meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)； pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新； fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

3.3 gossip通信的10000端口

每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping消息之后返回pong消息。

4、网络抖动

真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。为解决这种问题，Redis Cluster 提供了一种选项cluster­node­timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的重新复制)。

5、Redis集群选举原理分析

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：1.slave发现自己的master变为FAIL2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)6.slave广播Pong消息通知其他集群节点。
从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票•延迟计算公式： DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。

6、集群脑裂数据丢失问题

redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：

min-replicas-to-write 1
//写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如集群总共三个节点可以配置1，加上leader就是2，超过了半数

注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

7、集群是否完整才能对外提供服务

当redis.conf的配置cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。

8、Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。 奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

9、Redis集群对批量操作命令的支持

对于类似mset，mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XX}，这样参数数据分片hash计算的只会是大括号里的值，这样能确保不同的key能落到同一slot里去，示例如下：

mset {xiaohua}:name xiaohua {xiaohua}:age 19

假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，Redis只会用大括号里的 xiaohua 做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。

---

四、总结

Redis集群架构应该是生产环境中最受欢迎的。原因上面已经介绍的很清楚了。本片文章重在如何搭建Redis集群，以及Redis集群环境中的各种问题，例如脑裂问题、集群的选举原理等。搞懂这些就可以。