Redis-主从、哨兵、集群

文章目录

• Redis集群
• • 主从复制
  • • 概述
    • 复制原理
    • 作用
    • 注意问题
    • 配置
  • 哨兵模式(sentinel)
  • • 概述
    • 基本原理
    • 工作机制
    • 配置启动
    • 复制延时
    • 故障恢复
    • 注意问题
  • Cluster模式
  • • 使用
    • 节点原理
    • 故障恢复
    • `cluster`集群特点：

Redis集群

主从复制

概述

​ 是指将一台

Redis

服务器的数据，复制到其他的

Redis

服务器。前者称为主节点(

master

)，后者称为从节点(

slave

),数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台

Redis

服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

复制原理

​

slave

启动成功连接到

master

后会发送一个

sync

命令，

Master

接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，

master

将传送整个数据文件到

slave

,以完成一次完全同步。

全量复制：

​

slave

服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：

​

Master

继续将新的所有收集到的修改命令依次传给

slave

，完成同步。但是只要是重新连接

master

，一次完全（全量复制）将被自动执行

作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写

  Redis

  数据时应用连接主节点，读

  Redis

  数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高

  Redis

  服务器的并发量。
• 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
• 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是

  Redis

  高可用的基础

注意问题

1. 丛机只有第一次连接会全量复制，连接之后会使用增量复制
2. 主机宕机之后重新连接，情况会照旧
3. 主机宕机后，从机会原地待命，不会变成主机
4. 从机宕机后，重启情况会照旧

配置

• 复制三个配置文件：

  

• 主机文件配置

  port 6379
  bind 127.0.0.1         
  daemonize yes             
  logfile "/Users/xiao7/devTool/redis/redis-cluster/redis-6379.log"              
  dir  ./               
  masterauth 123456               
  requirepass 123456              
  
  appendonly yes                  
  appendfilename appendonly-6379.aof
  
  
  save 900 1 
  dbfilename dump-6379.rdb
             

• 从机配置

  port 6380
  bind 127.0.0.1         
  daemonize yes             
  logfile "/Users/xiao7/devTool/redis/redis-cluster/redis-6380.log"              
  dir  ./               
  masterauth 123456               
  requirepass 123456              
  
  appendonly yes                  
  appendfilename appendonly-6380.aof
  
  
  save 900 1 
  dbfilename dump-6380.rdb
  
  slaveof 127.0.0.1 6379
             

• 分别启动并查看集群情况

  redis-server redis-6379.conf
             

  

哨兵模式(sentinel)

概述

主从模式的弊端就是不具备高可用性，当

master

挂掉以后，

Redis

将不能再对外提供写入操作，因此sentinel应运而生。

sentinel

模式是建立在主从模式的基础上，如果只有一个

Redis

节点，

sentinel

就没有任何意义

基本原理

• 当

  master

  挂了以后，

  sentinel

  会在

  slave

  中选择一个做为

  master

  ，并修改它们的配置文件，其他

  slave

  的配置文件也会被修改，比如

  slaveof

  属性会指向新的

  master

• 当

  master

  重新启动后，它将不再是

  master

  而是做为

  slave

  接收新的

  master

  的同步数据

• sentinel

  因为也是一个进程有挂掉的可能，所以

  sentinel

  也会启动多个形成一个

  sentinel

  集群
• 多

  sentinel

  配置的时候，

  sentinel

  之间也会自动监控
• 当主从模式配置密码时，

  sentinel

  也会同步将配置信息修改到配置文件中，不需要担心
• 一个

  sentinel

  或

  sentinel

  集群可以管理多个主从

  Redis

  ，多个

  sentinel

  也可以监控同一个

  redis

• sentinel

  最好不要和

  Redis

  部署在同一台机器，不然

  Redis

  的服务器挂了以后，

  sentinel

  也挂了

工作机制

• 每个

  sentinel

  以每秒钟一次的频率向它所知的

  master

  ，

  slave

  以及其他

  sentinel

  实例发送一个

  PING

  命令
• 如果一个实例距离最后一次有效回复

  PING

  命令的时间超过

  down-after-milliseconds

  选项所指定的值， 则这个实例会被

  sentinel

  标记为主观下线。
• 如果一个

  master

  被标记为主观下线，则正在监视这个

  master

  的所有

  sentinel

  要以每秒一次的频率确认

  master

  的确进入了主观下线状态
• 当有足够数量的

  sentinel

  （大于等于配置文件指定的值）在指定的时间范围内确认

  master

  的确进入了主观下线状态， 则

  master

  会被标记为客观下线
• 在一般情况下， 每个

  sentinel

  会以每

  10

  秒一次的频率向它已知的所有

  master

  ，

  slave

  发送

  INFO

  命令
• 当

  master

  被

  sentinel

  标记为客观下线时，

  sentinel

  向下线的

  master

  的所有

  slave

  发送

  INFO

  命令的频率会从

  10

  秒一次改为

  1

  秒一次
• 若没有足够数量的

  sentinel

  同意

  master

  已经下线，

  master

  的客观下线状态就会被移除；

  若

  master

  重新向

  sentinel

  的

  PING

  命令返回有效回复，

  master

  的主观下线状态就会被移除

配置启动

• 配置文件

  

• 配置信息

  daemonize no
  logfile "./sentinel.log"
  dir "/Users/xiao7/devTool/redis/redis-sentinel"
  
  #判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数
  # mymaster为哨兵的服务名称
  sentinel monitor mymaster 127.0.0.1 6380 1
  sentinel auth-pass mymaster 123456
  #判断master主观下线时间，默认30s
             

• 启动

  redis-sentinel sentinel.conf
             

复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

故障恢复

主机挑选

1. 选择优先级最小机器，优先级在

   redis.conf

   中默认

   slave-priority 100

   ，值越小优先级越高
2. 选择偏移量最大的，偏移量是指获得主机数据最多的机器
3. 选择

   uuid

   最小的机器，

   uuid

   是

   redis

   启动自动生成的

   uuid

注意问题

1. 主机宕机后选举完后重新连接，那么它就会成为从机

Cluster模式

​

sentinel

模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或

sentinel

模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个

Redis

实例中。

cluster

模式的出现就是为了解决单机

Redis

容量有限的问题，将

Redis

的数据根据一定的规则分配到多台机器。

​

cluster

可以说是

sentinel

和主从模式的结合体，通过

cluster

可以实现主从和

master

重选功能，所以如果配置两个副本三个分片的话，就需要六个

Redis

实例。因为

Redis

的数据是根据一定规则分配到

cluster

的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用

• 实例开启集群

cluster-enabled yes    打开集群模式
cluster-config-file nodes-6379.conf  设定节点配置文件名
cluster-node-timeout 15000   设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换
           

• 创建集群

redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

redis-cli -c -p 6379 # 集群连接集群
           

使用集群不需要配置主从复制信息，需要配置主从密码，只需要将

redis

配置文件中的

cluster-enable

配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。

节点原理

• 分配

  一个集群至少要有三个主节点。选项

  --cluster-replicas 1

  表示我们希望为集群中的每个主节点创建一个从节点。分配原则尽量保证每个主数据库运行在不同的

  IP

  地址，每个从库和主库不在一个

  IP

  地址上。

• solt

  插槽

  一个

  Redis

  集群包含

  16384

  个插槽（

  hash slot

  ）， 数据库中的每个键都属于这

  16384

  个插槽的其中一个， 集群使用公式

  CRC16(key) % 16384

  来计算键

  key

  属于哪个槽， 其中

  CRC16(key)

  语句用于计算键

  key

  的

  CRC16

  校验和 。集群中的每个节点负责处理一部分插槽。

  不在一个slot下的键值，是不能使用mget,mset等多键操作

故障恢复

• 主节点宕机恢复后变成从机
• 如果某一段插槽的主从都挂掉，而

  cluster-require-full-coverage yes

  ，那么 ，整个集群都挂掉，如果

  cluster-require-full-coverage no

  ，那么，该插槽数据全都不能使用，也无法存储。

cluster

集群特点：

• 多个

  redis

  节点网络互联，数据共享
• 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用
• 不支持同时处理多个

  key

  （如

  MSET/MGET

  ），因为

  redis

  需要把

  key

  均匀分布在各个节点上，

  并发量很高的情况下同时创建

  key-value

  会降低性能并导致不可预测的行为
• 支持在线增加、删除节点
• 客户端可以连接任何一个主节点进行读写