比较几种Redis集群方案_Redis_

一、概述

在Redis3.0以前的集群一般是借助哨兵sentinel工具来监控主节点的状态，如果主节点异常，则会做主从切换，将某一台slave作为master。哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，集群会需要十几秒甚至几十秒的时间用于判断主节点下线，并选举一个从节点成为新的主节点。在某宝双11这样高并发的场景如果出现Redis主节点访问瞬断是一件非常可怕的事，这意味着几千万的商品、订单查询请求将直接请求数据库，数据库很可能因为大批量的查询请求而崩溃。

哨兵模式通常只有一个主节点对外提供服务，没法支持很高的并发，假设一个Redis节点允许支持10W的并发，但面对双11几千万的并发量还是捉襟见肘的，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

哨兵模式

Redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置简单。高可用集群相较于哨兵集群，至少不会出现主节点下线后，整个集群在一段时间内处于不可用状态，直到选举出主节点。因为高可用集群有多个主节点，当我们需要向整个Redis服务写入大批量数据时，数据会根据写入的key算出一个hash值，将数据落地到不同的主节点上，所以当一个主节点下线后，落地到其他主节点的写请求还是正常的。

高可用集群模式

二、Redis高可用集群搭建

Redis集群需要至少三个主节点，我们这里搭建三个主节点，并且给每个主节点再搭建一个从节点，总共6个Redis节点，端口号从8001~8006，这里笔者依旧是在一台机器上部署六个节点，搭建步骤如下：

配置1-1

#在Redis安装目录下创建一个config和data目录，并将redis.conf文件拷贝到config目录下并更名为redis-8001.conf进行配置修改。有部分配置再之前的主从&哨兵集群有讲解过，这里便不再赘述。

port 8001

protected-mode no

daemonize yes

pidfile "/var/run/redis-8001.pid"

logfile "8001.log"

dir "/home/lf/redis-6.2.1/data"

dbfilename "dump-8001.rdb"

#bind 127.0.0.1 -::1

appendonly yes

appendfilename "appendonly-8001.aof"

requirepass "123456"

#设置集群访问密码

masterauth 123456

#启动集群模式

cluster-enabled yes

#集群节点信息文件，这里800x最好和port对应上

cluster-config-file nodes-8001.conf

#设置节点超时时间，单位：毫秒

cluster-node-timeout 15000

修改完毕redis-8001.conf配置后，我们复制该配置并更名为redis-8002.conf、redis-8003.conf、redis-8004.conf、redis-8005.conf、redis-8006.conf，然后我们将文件里的8001分别替换成8002、8003、8004、8005、8006，可以批量替换：

:%s/源字符串/目的字符串/g

注意，如果集群是搭建在不同的服务器上，大家还要在每台服务器上执行下面的命令关闭下防火墙，避免出现因为防火墙导致不同服务器的Redis进程无法互相访问：

systemctl stop firewalld # 临时关闭防火墙

systemctl disable firewalld # 禁止开机启动

之后，我们单独修改redis-8001.conf的配置：

min-replicas-to-write 1

这个配置可以让我们在向主节点写数据时，主节点必须至少同步到一个从节点才会返回，如果配3则主节点必须同步到3个节点才会返回，这个配置可以在主节点下线，从节点切换为主节点时减少数据的丢失，但这个配置也不能完全规避在主节点下线时数据的丢失，并且存在性能的损耗，因为主节点必须确认数据同步到一定量的从节点，才能将客户端的请求返回。

现在，我们依次启动端口为8001~8006的Redis服务：

[root@master redis-6.2.1]# src/redis-server config/redis-8001.conf

[root@master redis-6.2.1]# src/redis-server config/redis-8002.conf

[root@master redis-6.2.1]# src/redis-server config/redis-8003.conf

[root@master redis-6.2.1]# src/redis-server config/redis-8004.conf

[root@master redis-6.2.1]# src/redis-server config/redis-8005.conf

[root@master redis-6.2.1]# src/redis-server config/redis-8006.conf

之前创建的6个Redis服务还是独立的服务，下面我们来看下将这6个服务组成一个集群的命令：

[root@master redis-6.2.1]# src/redis-cli --cluster help

Cluster Manager Commands:

  create         host1:port1 ... hostN:portN #组成集群的Redis服务的IP和端口

                 --cluster-replicas #集群副本数量，填N代表每个主节点有N个从节点
……

现在，我们按照上面的命令将6个Redis服务组成一个集群，我们有6个Redis服务，所以会有3个主节点，3个从节点，--cluster-replicas的参数我们应该填1：

#创建集群

[root@master redis-6.2.1]# src/redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.6.86:8001 192.168.6.86:8002 192.168.6.86:8003 192.168.6.86:8004 192.168.6.86:8005 192.168.6.86:8006

>>> Performing hash slots allocation on 6 nodes...

Master[0] -> Slots 0 - 5460

Master[1] -> Slots 5461 - 10922

Master[2] -> Slots 10923 - 16383

Adding replica 192.168.6.86:8005 to 192.168.6.86:8001

Adding replica 192.168.6.86:8006 to 192.168.6.86:8002

Adding replica 192.168.6.86:8004 to 192.168.6.86:8003

>>> Trying to optimize slaves allocation for anti-affinity

[WARNING] Some slaves are in the same host as their master

#<1>

M: 28ad6b59866832b13dbd58dd944e641862702e23 192.168.6.86:8001

   slots:[0-5460] (5461 slots) master

M: baf630fe745d9f1db7a58ffb96e180fab1047c79 192.168.6.86:8002

   slots:[5461-10922] (5462 slots) master

M: 115a626ee6d475076b096181ab10d3ab6988cc04 192.168.6.86:8003

   slots:[10923-16383] (5461 slots) master

S: 54b6c985bf0f41fa1b92cff7c165c317dd0a30c7 192.168.6.86:8004

   replicates baf630fe745d9f1db7a58ffb96e180fab1047c79

S: 9c6f93c3b5329e60032b970b57e599b98961cba6 192.168.6.86:8005

   replicates 115a626ee6d475076b096181ab10d3ab6988cc04

S: aa6ce37e876660161403a801adb8fc7a79a9d876 192.168.6.86:8006

   replicates 28ad6b59866832b13dbd58dd944e641862702e23

Can I set the above configuration? (type 'yes' to accept): yes #<2>

>>> Nodes configuration updated

>>> Assign a different config epoch to each node

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join

>>> Performing Cluster Check (using node 192.168.6.86:8001)

#<3>

M: 28ad6b59866832b13dbd58dd944e641862702e23 192.168.6.86:8001

   slots:[0-5460] (5461 slots) master

   1 additional replica(s)

S: aa6ce37e876660161403a801adb8fc7a79a9d876 192.168.6.86:8006

   slots: (0 slots) slave

   replicates 28ad6b59866832b13dbd58dd944e641862702e23

M: baf630fe745d9f1db7a58ffb96e180fab1047c79 192.168.6.86:8002

   slots:[5461-10922] (5462 slots) master

   1 additional replica(s)

S: 9c6f93c3b5329e60032b970b57e599b98961cba6 192.168.6.86:8005

   slots: (0 slots) slave

   replicates 115a626ee6d475076b096181ab10d3ab6988cc04

M: 115a626ee6d475076b096181ab10d3ab6988cc04 192.168.6.86:8003

   slots:[10923-16383] (5461 slots) master

   1 additional replica(s)

S: 54b6c985bf0f41fa1b92cff7c165c317dd0a30c7 192.168.6.86:8004

   slots: (0 slots) slave

   replicates baf630fe745d9f1db7a58ffb96e180fab1047c79

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

我们节选创建集群的部分返回来解析，下面有3个M和3个S，分别代表主节点master和从节点slave，之后是节点的ID、IP+端口，集群默认会使用我们输入的前三个服务作为主节点，根据我们之前输入的参数，端口号8001、8002、8003的服务作为主节点。主节点还会有该节点所对应的槽位，Redis会将数据划分为16384个槽位（slots），每个节点负责存储一部分槽位，比如8001对应的槽位是[0,5460]，8002对应的槽位是[5461,10922]，8003对应的槽位是[10923,16383]，当我们要存储或读取一个key值时，Redis客户端会根据key的hash值去对应槽位的主节点执行命令。我们再来看下从节点，从节点的格式大部分和主节点类似，除了槽位那部分，从节点可以根据replicates {masterID}查询该节点对应的主节点ID，比如8004从节点对应主8002主节点，8005从节点对应8003主节点，8006从节点对应主节点8001。

#<1>

M（主节点）: 28ad6b59866832b13dbd58dd944e641862702e23（节点ID） 192.168.6.86:8001（节点的IP和端口）

   slots:[0-5460] (5461 slots) master（节点槽位，key的hash值在0~5460会落地到该节点）

M: baf630fe745d9f1db7a58ffb96e180fab1047c79 192.168.6.86:8002

   slots:[5461-10922] (5462 slots) master

M: 115a626ee6d475076b096181ab10d3ab6988cc04 192.168.6.86:8003

   slots:[10923-16383] (5461 slots) master

S: 54b6c985bf0f41fa1b92cff7c165c317dd0a30c7 192.168.6.86:8004

   replicates baf630fe745d9f1db7a58ffb96e180fab1047c79

S: 9c6f93c3b5329e60032b970b57e599b98961cba6 192.168.6.86:8005

   replicates 115a626ee6d475076b096181ab10d3ab6988cc04

S（从节点）: aa6ce37e876660161403a801adb8fc7a79a9d876（节点ID） 192.168.6.86:8006（节点的IP和端口）

   replicates 28ad6b59866832b13dbd58dd944e641862702e23（该从节点对应主节点的ID）

如果同意Redis集群的主从划分，则在<2>处输入yes并回车。<3>处则是真实划分，如果没有意外内容应该跟<1>处大致类似。之前，我们把所有的节点都搭建在一台服务器上，如果我们把节点部署在多台服务器上，那么Redis在划分主从时，会刻意将主从节点划分到不同的服务器上，这是因为Redis期望如果一台服务器挂了，不会导致一整个主从集群都不可用，将主从划分到不同机器上，可以保证如果主节点所在的服务器挂了，从节点能切换成主节点。

如果我们想查看集群信息，可以连接到任意一个节点，执行CLUSTER NODES或者CLUSTER INFO命令：

[root@master redis-6.2.1]# src/redis-cli -a 123456 -c -p 8001

127.0.0.1:8001> CLUSTER NODES

aa6ce37e876660161403a801adb8fc7a79a9d876 192.168.6.86:8006@18006 slave 28ad6b59866832b13dbd58dd944e641862702e23 0 1618317182151 1 connected

baf630fe745d9f1db7a58ffb96e180fab1047c79 192.168.6.86:8002@18002 master - 0 1618317187163 2 connected 5461-10922

9c6f93c3b5329e60032b970b57e599b98961cba6 192.168.6.86:8005@18005 slave 115a626ee6d475076b096181ab10d3ab6988cc04 0 1618317186161 3 connected

115a626ee6d475076b096181ab10d3ab6988cc04 192.168.6.86:8003@18003 master - 0 1618317184000 3 connected 10923-16383

54b6c985bf0f41fa1b92cff7c165c317dd0a30c7 192.168.6.86:8004@18004 slave baf630fe745d9f1db7a58ffb96e180fab1047c79 0 1618317186000 2 connected

28ad6b59866832b13dbd58dd944e641862702e23 192.168.6.86:8001@18001 myself,master - 0 1618317184000 1 connected 0-5460

127.0.0.1:8001> CLUSTER INF

提示： 本文由神整理自网络，如有侵权请联系本站删除！
本站声明：
1、本站所有资源均来源于互联网，不保证100%完整、不提供任何技术支持；
2、本站所发布的文章以及附件仅限用于学习和研究目的;不得将用于商业或者非法用途；否则由此产生的法律后果，本站概不负责！

上一篇：解析Redis Cluster原理_Redis_

下一篇：Redis缓存-序列化对象存储乱码问题的解决_Redis_