redis之集群搭建

集群搭建

环境

使用一台服务器启动6个redis进程，用来创建一个3主3从的集群。redis版本是6.2.13，该版本下redis-cli有集群初始化的功能。

配置文件

#设置集群模式启动
cluster-enabled yes
#集群配置文件存放地方，由服务器进程自动生成，里没有主备节点，slots分配的信息，这里的信息会实时动态更新
cluster-config-file /usr/local/redis/conf/nodes-4000.conf
port 4000
pidfile /var/run/redis_4000.pid
logfile "/usr/local/redis/logs/cluster-4000.log"
dbfilename dump4000.rdb

#复制配置文件
sed 's/4000/4001/g' cluster-4000.conf > cluster-4001.conf

集群初始化

redis-cli --cluster create 192.168.1.235:4000 192.168.1.235:4001 192.168.1.235:4002 \
   192.168.1:4003 192.168.1:4004 192.168.1:4005 --cluster-replicas 1

• 这里需要注意的是默认使用前3个节点作为主节点，后3个节点为备节点
• redis-cli --cluster help 可以查看集群相关命令帮助

集群管理

# redis-cli -c 连接集群
redis-cli  -h 192.168.1.235 -p 4000 -c

# 集群命令
cluster help
cluster info 
cluster nodes
cluster slots
# 备节点上执行，切换连接到的备节点为主节点
cluster failover

#查看key会被分配到哪个slots, 根据cluster slots可以发现slots在哪个节点
cluster keyslot xxx


#{dsq}1  {dsq}2  会被分配到相同的slots, 因为计算的hash时候会使用{}里面的字符
#集群模式只能用db0

集群的高可用性

在3个主节点(A,B,C)的redis中，每个节点都会通过心跳检查其他节点的状态。当节点A通过心跳发现与节点B通信故障，超过一定时间都无法正常通信（cluster-node-timeout），就会认为节点B是可疑下线。同时节点A会将“A认为B可疑下线”这条消息发送给集群的其他节点。当C发现节点B可疑下线，并且收到A发来消息，那就表示集群中超过一半的节点认为B可疑下线，这时候C就认为节点B是下线了，这个消息也会被发送给集群其他节点，所以A最后也认为B下线了。也就是集群中的节点达成共识是需要一定的时间的。
3主3从的集群，单个主节点故障后，剩余的两个主节点可以达成节点下线的共识（3个从节点无投票权），然后进行主备切换。但是如果其中两个主节点同时故障，那就无法满足切换条件，集群会进入fail状态。如果是先一个主节点故障，然后从节点顶替上来成为主节点之后，然后另外一个主节点故障，那么还是能正常切换的(也就是两个节点故障的时间间隔要大于cluster-node-timeout)，因为集群中总是能有两个主节点正常运行，满足达成共识的条件。

# 可用性相关配置
// 超时15秒认为节点可疑下线
cluster-node-timeout 15000
// 从节点与主节点断开连接时间太长，就无法顶替主节点，因为数据太旧了
// 这个配置越大表示允许断开时间越长
cluster-replica-validity-factor 10
// 如果主节点A节点有两个从节点，主节点B没有从节点，那么节点A的其中一个从节点可以自动迁移成为B的从节点
cluster-migration-barrier 1
// yes表示如果有部分slots异常，就认为集群是fail状态
// no则认为集群依然是正常状态，现象是访问部分key出现异常，部分正常，给发现问题带来难度（如果监控能监控到就没有坏处）
cluster-require-full-coverage no
// yes表示主节点异常时不自动切换到从节点
// no表示自动进行切换
cluster-replica-no-failover no
// 集群fail状态的时候依然可读
cluster-allow-reads-when-down no

性能测试

[root@testdsq conf]# redis-benchmark -h ip1 -p port1  -n 1000 -q --cluster
Cluster has 3 master nodes:

Master 0: 0d7bcb8b43cebcdd161f7c39ff6eb8a3eb36887b ip1:port1
Master 1: 70564659fca38b53e6b01ee369dd943b01b4af9b ip2:port2
Master 2: d7231a0ed4f836cc432cd3a5de81186a69d24dfb ip3:port3

PING_INLINE: 3968.25 requests per second
PING_BULK: 3968.25 requests per second
SET: 3984.06 requests per second
GET: 4000.00 requests per second
INCR: 3968.25 requests per second
LPUSH: 3968.25 requests per second
RPUSH: 3968.25 requests per second
LPOP: 3937.01 requests per second
RPOP: 3968.25 requests per second
SADD: 3968.25 requests per second
HSET: 4000.00 requests per second
SPOP: 3984.06 requests per second
ZADD: 3984.06 requests per second
ZPOPMIN: 3984.06 requests per second
LPUSH (needed to benchmark LRANGE): 3968.25 requests per second
LRANGE_100 (first 100 elements): 3984.06 requests per second
LRANGE_300 (first 300 elements): 3984.06 requests per second
LRANGE_500 (first 450 elements): 3968.25 requests per second
LRANGE_600 (first 600 elements): 3968.25 requests per second
MSET (10 keys): 3984.06 requests per second

对比单节点测试

[root@testdsq conf]# redis-benchmark -h ip -p port  -n 1000 -q
PING_INLINE: 62500.00 requests per second
PING_BULK: 66666.67 requests per second
SET: 71428.57 requests per second
GET: 71428.57 requests per second
INCR: 76923.08 requests per second
LPUSH: 71428.57 requests per second
RPUSH: 71428.57 requests per second
LPOP: 66666.67 requests per second
RPOP: 58823.53 requests per second
SADD: 76923.08 requests per second
HSET: 76923.08 requests per second
SPOP: 71428.57 requests per second
ZADD: 71428.57 requests per second
ZPOPMIN: 66666.67 requests per second
LPUSH (needed to benchmark LRANGE): 71428.57 requests per second
LRANGE_100 (first 100 elements): 33333.34 requests per second
LRANGE_300 (first 300 elements): 11363.64 requests per second
LRANGE_500 (first 450 elements): 11494.25 requests per second
LRANGE_600 (first 600 elements): 9900.99 requests per second
MSET (10 keys): 71428.57 requests per second

• 集群比单节点性能差了20倍，为什么？
• 当访问节点A，但是key在节点B的时候，客户端会收到节点A发送的一个类似重定向的应答，然后客户端访问节点B获取key; 客户端可以通过缓存节点的slot信息，在访问前先计算key在哪个节点上，从而优化访问。