Redis集群搭建和常见问题

三流程序员03
311 阅读7分钟

介绍

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。

Redis集群不需 要sentinel哨兵，也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的 性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

集群搭建

image.png

redis集群模式下，从节点不支持读，只能对master节点读写

redis集群需要至少三个master节点(半数选举)，这里用三台机器部署6个redis实例，每台机器一主一从

一、修改配置文件

daemonize yes
port 8001（分别对每个机器的端口号进行设置）
pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件
dir /usr/local/redis‐cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会
丢失数据）
cluster‐enabled yes（启动集群模式）
cluster‐config‐file nodes‐8001.conf（集群节点信息文件，重新启动集群时自动加载这里的配置）
cluster‐node‐timeout 10000 # 不能设置太小，方式网络抖动时，认定该节点故障，频繁切换主从
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
protected‐mode no （关闭保护模式）
appendonly yes

requirepass 123456 (设置redis访问密码)
masterauth 123456 (设置集群节点间访问密码，跟上面一致)

启动6个redis实例

image.png

二、创建集群

首先需要确保机器间可以联通，这里因为防火墙导致连不上其他机器，浪费了半个小时

执行命令

src/redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.119.128:7001 
192.168.119.128:7002 192.168.119.130:8001 192.168.119.130:8002 192.168.119.129:9001 192.168.119.129:9002

image.png

可以看到主从和分片信息，redis在分配主从的时候不会分配到一台机器上，防止一台机器挂掉，整个集群不能使用，保证高可用

查看集群信息

image.png

测试，成功同步到对应从节点

image.png

SpringBoot操作redis集群

一、引入pom依赖

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

二、yml配置

spring:
  redis:
    database: 0
    timeout: 3000
    password: 123456
#    sentinel:    #哨兵模式
#      master: mymaster #主服务器所在集群名称
#      nodes: 192.168.65.60:26379,192.168.65.60:26380,192.168.65.60:26381
    cluster:
      nodes: 192.168.119.128:7002,192.168.119.129:9002,192.168.119.130:8001,192.168.119.128:7001,192.168.119.130:8002,192.168.119.129:9001
    lettuce:
      pool:
        max-idle: 50
        min-idle: 10
        max-active: 100
        max-wait: 1000

三、Controller

@RestController
public class IndexController {

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

    @Autowired
    private StringRedisTemplate stringRedisTemplate;
    
    @RequestMapping("/test_cluster")
    public void testSentinel() throws InterruptedException {
        int i = 1;
        while (true){
            try {
                stringRedisTemplate.opsForValue().set("hero"+i, i+""); //jedis.set(key,value);
                System.out.println("设置key："+ "hero" + i);
                i++;
                Thread.sleep(1000);
            }catch (Exception e){
                logger.error("错误：", e);
            }
        }
    }

}

原理分析

分片逻辑

JedisCluster对key进行hash算法计算出槽位信息，再根据槽位信息计算到该设置到哪个集群上(连接集群时会将槽位配置信息缓存到本地客户端)

public class CRC16 {

    public static void main(String[] args){
        String str="name1";
        System.out.println(JedisClusterCRC16.getCRC16(str)%16384);
        System.out.println(JedisClusterCRC16.getCRC16(str)& (16384 - 1)); //12933
    }
    
}

image.png

跳转重定位：如果服务端信息变更，查找的key不在客户端计算出的机器中，会向客户端发送一个跳转指令（携带要操作key的节点地址），客户端跳转到正确节点操作，并且更新本地缓存节点信息

Redis内部通信

redis cluster节点间采取gossip协议进行通信

image.png

gossip协议包含多种消息，包括ping，pong，meet，fail等等。

gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上 去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000

Redis选举原理

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master 可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

  1. slave发现自己的master变为FAIL
  2. 将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息
  3. 其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个 epoch只发送一次ack（只回复第一个接收到的请求）
  4. 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两 个，当其中一个挂了，只剩一个主节点是不能选举成功的)
  5. slave广播Pong消息通知其他集群节点。 从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟时间，确保我们等待 FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票

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

群脑裂数据丢失问题

当主节点与所有从节点发生网络断开时，会触发选举，重新选举出一个主节点，但是原来的主节点(孤立)还存在，这时客户端就会向两个主节点都写入数据；如果网络恢复，原来的主节点变为从节点（主节点同步数据过来），就会造成这个节点中原来的数据丢失。

规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：

min‐replicas‐to‐write 1 //写数据成功最少同步的slave数量（孤立的主节点没有slave，不会写入成功）

这个数量可以模仿大于半数机制配置，比如 集群总共三个节点可以配置1，加上leader就是2，超过了半数 注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能 提供服务了，需要具体场景权衡选择。

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

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

mset {user1}:1:name zhuge {user1}:1:age 18

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

avatar
文章
阅读
粉丝