redis的三种集群方案(主从复制、哨兵模式、集群模式)

redis的三种集群方案(主从复制、哨兵模式、集群模式)

单个redis的读写能力是有限的(虽然已经很强了)，并且存在不稳定性。当唯一的redis服务宕机了，就没有可用的redis服务了，另外当硬件出现问题，单机的数据便无法恢复。redis集群的出现解决了单节点故障的问题，同时强化了redis的读写能力(负载均衡)

主从复制

主从复制是指一台redis服务器的数据复制到其他的redis服务器，前者为主节点(master),后者为从节点(slave)。数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台redis服务器都是主节点，一个主节点可以有0或者多个从节点，但从节点只能有一个主节点。

主节点提供读写服务，从节点提供读服务，多个从节点分担读负载，提高了redis的并发量。

主从复制原理

全量复制：当从节点(slave)启动成功并连接到主节点(master)后，会向主节点发送sync命令，请求数据同步。主节点接收到命令后会启动一个子进程，将数据写入数据文件中(RDB操作)，待数据写入完毕后，会将数据文件传送给从节点，从节点接收到文件后保存到磁盘上，并将数据加载到内存中，完成一次全量复制。

增量复制：在完成一次全量复制后，如果主节点收到写操作的命令时，会以异步方式将命令复制给从节点(在全量复制期间，如果主节点接收到了新的写操作命令，会先存入缓存，待从节点完成数据同步后，将新的写操作命令复制给从节点)

主从复制的优缺点

优点：

  • 实现了读写分离，缓解了主节点读操作的压力，提高了可用性，解决了单机故障问题

  • 主从复制期间主节点与从节点都是非阻塞的方式，仍然可用

缺点：

  • 如果主节点发生宕机，需要手动切换主节点
  • 如果RDB文件过大，同步过程比较耗时

部署redis主从复制

这里采用的是同一台服务器不同端口号的部署方式(因为没有多余服务器= =)

1.准备环境

准备三个redis,修改相应的redis配置参数，端口号分别为6379,6380,6381，之后启动三个redis服务

2.配置从节点

默认情况下，每台redis服务都是主节点，可以通过info replication命令可以查询
登陆redis客户端之后查询节点状态

[root@localhost test]# ./redis-node3/src/redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

通过slaveof命令可以配置主节点信息

127.0.0.1:6381> slaveof 127.0.0.1 6379
OK

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:71
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

通过slaveof no one 命令让该节点不再复制，该节点更改为主节点
127.0.0.1:6381> slaveof 127.0.0.1 6379
OK

除了命令的形式(命令形式只是暂时的，redis服务重启后从节点就会恢复为主节点)也可以在配置文件中写死，这样在服务重启时也会配置主节点的信息

主节点不需要配置，之后主节点写操作命令会增量复制到从节点上，相应key的数值也能获取到。主节点可以进行读写操作，从节点可以进行读操作，如果从节点执行写操作会报错

注意:我这里部署的是redis5.0之前的版本，redis5.0之后的版本推荐用replicaof命令来替代slaveof命令(当然此命令也支持)，并且5.0之后的配置文件REPLICATION中的slaveof参数也更换为了replicaof

哨兵模式

对于主从复制，当主节点服务宕机后，就需要手动把一个从节点切换为主节点，需要人工干预，redis从2.8版本正式提供的哨兵模式(Sentinel)解决了这个问题，保证了服务的可用性

哨兵模式原理

哨兵的核心功能是在主从复制的基础上，哨兵引入了主节点的自动故障转移

1.哨兵的作用

  • 哨兵是一个独立的进程，通过发送命令，让redis服务返回主从节点的状态信息，哨兵之间也相互监控，本身没有主从节点之分
  • 当哨兵检测到主节点宕机时，会先对从节点进行竞选，将最佳的从节点切换为主节点，之后通过发布订阅模式通知其他从节点服务，修改配置，更换为复制新的主节点数据，旧的主节点也会变为从节点(即使服务恢复，也作为新的主节点的从节点)

2.服务下线

哨兵默认每隔1秒向redis服务发送PING命令,如果在规定的时间内(down-after-milliseconds参数配置，默认30秒)没有收到回复，则该哨兵会将该节点redis服务标记为下线(主观下线)

此时哨兵会询问其他节点的哨兵，确认该节点是否下线，如果多数哨兵认为主节点下线(部署多个哨兵建议为奇数个)，则主节点真正确认为下线(客观下线)，需要重新选出主节点(客观下线是主节点才有的概念，如果从节点或者单个哨兵发生故障，被哨兵主观下线后就结束了)

3.故障转移(failvoer)

  1. 在哨兵集群中选出一个Leader
  2. 由领头哨兵从节点中选出一个优先级最高的从节点，如果优先级相同，则从复制命令偏移量(同步的数据量)越大越优先，最后再比较进程ID越小越优先
  3. 选出新的主节点后，通过slaveof no one 命令使其成为独立节点，向其他节点发送slaveof masterip masterport命令让其他节点成为子节点

哨兵模式的优缺点

优点：

  • 哨兵模式基于主从模式，具备主从复制的优点
  • 具备了自动主从切换和故障转移，有了更高的可用性

缺点：

  • 只有主节点可以进行写操作，写操作收单机影响
  • 在线扩容比较复杂

哨兵模式的配置参数

与redis服务类似，哨兵也有自己的启动服务与配置文件

进入redis根目录执行命令
./src/redis-sentinel ./sentinel.conf
即可启动哨兵服务，前提是需要把配置文件中的配置参数改好

通过vi ./sentinel.conf来编辑配置参数，以下是常用的配置参数

protected-mode no ： 保护模式，yes开启，no关闭，建议关闭

port 26379 ： 监听端口号，默认为26379

daemonize yes ： 是否为后台启动， yes后台启动,no在终端运行，建议后台启动

dir /tmp : 哨兵的工作目录，默认为/tmp

pidfile /var/run/redis-sentinel.pid :
输出进程id(pid)的信息路径，默认为/var/run/redis-sentinel.pid

logfile ""  ： 日志存放路径，默认为空

sentinel monitor mymaster 127.0.0.1 6379 2 ： 
指定哨兵监控名为mymaster的主节点，ip为127.0.0.1，端口号为6379, 2表示当主节点宕机，至少需要两个哨兵主观认为下线才能进行故障转移

sentinel auth-pass <master-name> <password> ： 
当主节点设置了密码就需要密码认证，需要输入主机名和密码

sentinel down-after-milliseconds mymaster 30000 ： 
判断主节点掉线的时间，单位为毫秒，当超过指定的时间则哨兵主观上认为主节点下线，默认间隔时间为30秒

sentinel failover-timeout mymaster 180000 ：
故障转移的超时时间，单位毫秒，默认为 180秒

部署哨兵模式

由于哨兵模式是在主从复制基础上进行的改进，因此redis节点服务的部署方式与主从复制一致(从节点在配置文件的REPLICATION项的配置参数中设置主节点信息)

1.准备环境

按主从复制，搭建三个redis节点，端口号分别为6380,6381,6382，其中6380为主节点

2.修改各个节点的哨兵配置文件

vi ./sentinel.conf来编辑配置参数,相关参数修改如下
protected-mode no
port 26380
daemonize yes
pidfile “/opt/shen/redis-test1/redis-master/sentinel/redis-sentinel.pid”   路径需要写绝对路径
logfile "/opt/shen/redis-test1/redis-master/sentinel/sentinel.log"
dir "/opt/shen/redis-test1/redis-master/sentinel"
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel auth-pass mymaster 123456

3.运行哨兵

./src/redis-sentinel ./sentinel.conf

通过哨兵日志查看 tail -400f ./sentinel/sentinel.log

通过redis客户端登陆哨兵端口查看信息

4.模拟故障

通过客户端停掉主节点服务
redis-master]# ./src/redis-cli -p 6380
127.0.0.1:6380> auth 123456
OK
127.0.0.1:6380> shutdown
(0.92s)
not connected>

查看日志可以发现，之前的主节点客观下线，更换端口6382的为主节点，即时之前主节点恢复也会变成从节点

集群模式

集群，即redis cluster,redis3.0正式推出的分布式存储方案，它是去中心化的，客户端可以连接任意一个可用节点

采用多主多从(官方建议是至少3个主节点，最好是3主3从六个节点的集群模式)，每一个分区都是由一个节点多个从节点组成，节点与节点之间两两交互，共享数据分片(分区)，节点状态信息，主节点负责读写请求与集群信息维护，从节点只进行主节点数据与状态信息的复制

集群模式的原理

数据分区是集群中最核心的功能

redis创建了16384个虚拟哈希槽(slot),编号(0-16383),集群中每一个主节点负责一部分的哈希槽，每一个key通过CRC16算法校验后对16384取余(%16384)来决定放在那个哈希槽，通过哈希槽值找到对应的节点，跳转到该节点进行数据的存取操作

集群将数据分散到多个节点，一方面突破了redis单机内存大小的限制，存储容量大大增加，另一方面每一个主节点提供读写操作，缓解了之前集群方案的写操作的压力。

高可用(主从切换)是集群的第二核心功能

当集群只有三个主节点时，当主节点B挂了，那么整个集群会因为缺少编号5461-10922的哈希槽而不可用，当我们为三个主节点提供了从节点后，主节点挂了，从节点会成为主节点提供服务

主从切换流程如下(与哨兵模式类似)

  1. 从节点发现自己的主节点下线
  2. 广播FAILOVER_AUTH_REQUEST信息(请求故障转移)
  3. 其他节点收到消息，只有主节点响应，判断是否真的下线，发送FAILOVER_AUTH_ACK
  4. 发起故障转移的从节点收集确认信息，超过半数同意则切换为新的主节点
  5. 广播通知其他节点

集群模式的优缺点

优点：

  • 集群完全去中心化，多主多从(客户端不需要关注数据在存储在哪个节点，只关注集合整体)
  • 数据通过虚拟哈希槽分布到多个节点，可动态调整数据分布
  • 可以线性扩展(官方推荐不超过1000个)
  • 高可用，可以进行主从切换

缺点：

  • 客户端实现复杂(客户端在本地维护一份slot-node的映射关系，不需要重定向)，需要实现smart client
  • 数据通过异步复制，不保证数据的强一致性
  • 多个业务使用同一套集群，无法根据统计区分冷热数据，资源隔离性较差

集群模式的配置参数

redis-cluster的配置信息包含在redis.conf的REDIS CLUSTER中，以下是常用配置参数

cluster-enabled yes : 是否开启集群模式 yes为开启

cluster-config-file nodes-6379.conf
集群配置信息文件，由redis自行更新，不用手动配置，每一个节点都有对应的集群配置文件，需保证命名不冲突，默认配置文件名为nodes-6379.conf

cluster-node-timeout 15000 ：节点互联超时时间，单位毫秒，默认为15秒

cluster-require-full-coverage no : 所有哈希槽都正常才对外提供服务，建议设置为no

cluster-migration-barrier 1 : 主节点的从节点数量大于该值时，从节点才能迁移到其他单个的主节点上

部署集群模式

我这里只部署了三个主节点，建议是三主三从

1.准备环境

搭建三个redis主节点，端口号分别为6379,6380,6381

2.修改redis.conf配置文件

cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
cluster-require-full-coverage no
cluster-migration-barrier 1

3.运行redis服务并构建集群

运行三个redis服务
之后通过redis客户端创建(注意此命令是redis5.0之后才支持的)
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 --cluster-replicas 0 -a 123456

-a xxx 表示输入密码授权因为我之前设置了密码
redis-cli --cluster 表示群集操作
--cluster create 表示创建集群
--cluster-replicas n 表示一个主节点有n个从节点
如果节点数够多,则主从分配为：假设总共有m个节点数，master节点有m/(1+n)个，则前m/(1+n)个是主节点，其他是从节点，随机分配给主节点

4.运行后的集群状态

5.获取key值需要对应slot编号在对应节点的查找

参考网址

https://blog.csdn.net/weixin_45596022/article/details/113281023

https://blog.csdn.net/weixin_47062656/article/details/123187627

posted @ 2022-11-04 23:37  柯南。道尔  阅读(1876)  评论(0)  编辑  收藏  举报