Redis Cluster集群学习总结

只要平凡丶

于 2022-08-09 11:13:59 发布

阅读量181

点赞数

文章标签： redis 学习 java

本文链接：https://blog.csdn.net/weixin_45161367/article/details/126210811

版权

哨兵模式

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。
请添加图片描述

高可用集群模式

Redis3.0之后，Redis提供了高可用集群，由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵·也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，官方推荐不超过1000个节点。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单
在这里插入图片描述

redis集群搭建

redis集群需要至少三个master节点，我们这里搭建三个master节点，并且给每个master再搭建一个slave节点，总共6个redis节点，这里用三台机器部署6个redis实例，每台机器一主一从，搭建集群的步骤如下：

第一步：在第一台机器的/usr/local下创建文件夹redis-cluster，然后在其下面分别创建2个文件夾如下
1、mkdir -p /usr/local/redis-cluster
2、mkdir 8001 8004

第二步：把之前的redis.conf配置文件copy到8001下，修改如下内容：
1、daemonize yes
2、port 8001（分别对每个机器的端口号进行设置）
3、pidfile /var/run/redis_8001.pid  # 把pid进程号写入pidfile配置的文件
4、dir /usr/local/redis-cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会丢失数据）
5、cluster-enabled yes（启动集群模式）
6、cluster-config-file nodes-8001.conf（集群节点信息文件，这里800x最好和port对应上）
7、cluster-node-timeout 10000
8、# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
9、protected-mode  no   （关闭保护模式）
10、appendonly yes
如果要设置密码需要增加如下配置：
11、requirepass zhuge     (设置redis访问密码)
12、masterauth zhuge      (设置集群节点间访问密码，跟上面一致)
#为no时，表示其中一个小集群挂掉后，大集群仍然可用，yes就是大集群不可用。
13、cluster-require-full-coverage no 

第三步：把修改后的配置文件，copy到8004，修改第2、3、4、6项里的端口号，可以用批量替换：
:%s/源字符串/目的字符串/g 

第四步：另外两台机器也需要做上面几步操作，第二台机器用8002和8005，第三台机器用8003和8006

第五步：分别启动6个redis实例，然后检查是否启动成功
1、/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/800*/redis.conf
2、ps -ef | grep redis 查看是否启动成功
    
第六步：用redis-cli构建redis集群(redis5以前的版本集群是依靠ruby脚本redis-trib.rb实现)
# 下面命令里的1代表为每个创建的主节点创建一个从节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口18001(默认是在redis端口号上加1w)
# 默认会把前三个实例设置为master节点
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动
1、/usr/local/redis-5.0.3/src/redis-cli -a 123456 --cluster create 127.0.0.1:8001 127.0.0.1:8002 127.0.0.1:8003 127.0.0.1:8004 127.0.0.1:8005 127.0.0.13:8006 --cluster replicas 1

第七步：验证集群
1、连接任意一个客户端即可：./redis-cli -a -c -h -p (-a访问服务端密码，-c表示集群模式，指定ip地址和端口号）
    如：/usr/local/redis-5.0.3/src/redis-cli -a 123456 -c -h 192.168.0.61 -p 8001
2、进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表）
3、进行数据操作验证
4、关闭集群则需要逐个进行关闭，使用命令：
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.60 -p 8001 shutdown

第八步：如果节点关闭之后，想要重起集群，不需要执行--cluster create命令，只需要重新启动每个master节点就行，创建集群时会创建一个node.conf，这个配置文件记录了主从节点信息，以及每个master节点对应的槽位信息，节点重启时会根据这个配置文件来重新构建集群。

Java操作redis集群

Spring 整合Jedis

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

Spring Java代码

public class JedisClusterTest {
    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.0.61", 8001));
        jedisClusterNode.add(new HostAndPort("192.168.0.62", 8002));
        jedisClusterNode.add(new HostAndPort("192.168.0.63", 8003));
        jedisClusterNode.add(new HostAndPort("192.168.0.61", 8004));
        jedisClusterNode.add(new HostAndPort("192.168.0.62", 8005));
        jedisClusterNode.add(new HostAndPort("192.168.0.63", 8006));

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

Spring Boot整合Redis

<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: 8080

spring:
  redis:
    database: 0
    timeout: 3000
    password: 123456
    cluster:
      nodes: 192.168.0.61:8001,192.168.0.62:8002,192.168.0.63:8003,192.168.0.61:8004,192.168.0.62:8005,192.168.0.63:8006
   lettuce:
      pool:
        max-idle: 50
        min-idle: 10
        max-active: 100
        max-wait: 1000

SpringBoot Java代码

@RestController
public class JedisClusterController {

    private static final Logger logger = LoggerFactory.getLogger(JedisClusterController.class);

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @RequestMapping("/test_cluster")
    public void testCluster() throws InterruptedException {
       stringRedisTemplate.opsForValue().set("zhangsan", "888888");
       System.out.println(stringRedisTemplate.opsForValue().get("zhangsan"));
    }
}

Redis集群原理

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

槽位定位算法：

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

跳转重定位：

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

Redis集群节点间的通信机制：

维护集群元数据有两种方式：集中式和gossip，redis cluster节点间采取gossip协议进行通信。
集中式：
元数据一旦出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到，优点在于元数据的更新和读取，时效性非常好。不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。很多中间件都会借助zookeeper集中式存储元数据。
Gossip协议：
Gossip协议包含多种消息，包括ping，pong，meet，fail等。
meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；
ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；
pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新；
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。
Gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，但降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如8001，那么用于节点间通信的就是18001端口。不关闭防火墙的时候，需要同时打开redis服务端口和集群节点gossip通信端口。

网络抖动：

网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。
为解决这种问题，Redis Cluster 提供了一种配置cluster-node-timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果不配置该属性或者设置的时间很短，可能会导致主从频繁切换，甚者还会产生脑裂问题

Redis集群选举原理：

当slave发现自己的master变为fail状态时，会尝试进行Failover故障切换，会从多个slave中选举出新的master，过程如下：
1.slave发现自己的master变为fail
2.将自己记录的集群currentEpoch(选举周期)加1，并广播FAILOVER_AUTH_REQUEST信息
3.其他节点收到该信息，只有master会响应，master会判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
4.尝试故障切换的slave收集master返回的FAILOVER_AUTH_ACK
5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
6.slave广播Pong消息通知其他集群节点。
如果第一轮选举，两个slave的票数相同，你那么会进入下一轮选举，直到选举成功。为了解决票数相同问题，从节点并不是在主节点一进入FAIL状态就马上尝试发起选举，而是有一定延迟，确保fail 状态在集群中传播完成，slave如果立即尝试选举，其它masters可能还未感知到fail状态，可能会拒绝投票。
延迟计算公式：
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
random：确保每个节点发送选举的时间不同
SLAVE_RANK：表示此slave已经从master复制数据的总量的rank排名。Rank越小代表已复制的数据越新。这种方式下，理论上持有最新数据的slave将会首先发起选举。

集群脑裂数据丢失问题：

redis集群网络波动导致脑裂后，会有多个主节点对外提供写服务，一旦网络恢复，会将其中一个主节点变为从节点，这时变成从节点的这个节点数据就会丢弃全部数据，复制主节点数据。
可以在redis配置里加上参数：min-replicas-to-write 1（不能百分百避免数据丢失）表示客户端在往主节点写数据时，至少有1个从节点同步成功之后才通知客户端写成功了。这个值一般根据半数机制设置，比如主从一共三个节点，可以配置为1，表示1主+1从写成功，大于了3的半数。min-replicas-max-lag n秒，表示slave同步时间，如果超过n秒，表示没有写入成功。
注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

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

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

Redis集群批量操作命令

对于类似mset，mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XX}，这样参数数据分片hash计算的只会是大括号里的值，这样能确保不同的key能落到同一slot里去，示例如下：
mset {user1}name zhuge {user1}age 18
假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，redis只会用大括号里的 user1 做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。