关于Redis持久化和集群模式(主从,哨兵,去中心化)使用和介绍

发布于:2024-07-27 ⋅ 阅读:(25) ⋅ 点赞:(0)

持久化:

持久化介绍

把内存中的数据存储到磁盘的过程。同时也可以把磁盘中的数据加载到内存中

持久化实现

redis实现持久化的方式提供了两种:

  1. RDB快照模式,数据备份和恢复速度快。

    缺点: 数据完整性差。数据可能丢失多。

  2. AOF日志追加: 数据完整性高。

    缺点: 数据备份和恢复速度慢。

如果两种模式都打开了默认会优先使用AOF日志模式;

RDB:

RDB[redis database]: 快照模式。每隔一段时间对内存中的数据进行快照存储。 默认启用该模式

RDB触发:

1.手动触发:

savebgsave手动触发rdb。

保存的名称dump.rdb(可通过更改redis.conf文件dbfilename dump.rdb修改保存名称)

save该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。执行完成时候如果存在老的RDB文件,就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万,这种方式显然不可取。

bgsave:执行该命令时,Redis会在后台(fork())出一个新的线程单独异步进行快照操作,快照同时还可以响应客户端请求(不耽误主线程进行操作)(唯一的多线程操作)

2.自动触发: 通过配置文件。

需要修改配置文件:

### SNAPSHOTTING  ###
​
save 30 2 10 40 ...
表示:(30 2)每10s/2次 或 (10 40)每10s/40次 才 持久化一次
AOF:

AOF[append only file]: 日志[每执行一个写操作]追加模式,默认redis没有开启该模式。需要手动开启。

默认的配置文件

redis/redis.conf

appendonly no //是否开启aof模式
​
appendfilename "appendonly.aof" //aof持久化文件的名称
​
appendirname "appendonlydir" //aof存放的目录
​
appendfsync everysec //触发机制

开启aof

把配置文件中的appendonly yes即可

当启动redis服务器,会把日志文件中的命令从上到下执行一下。

集群模式:

redis集群作用

提高并发量,提高了可用性。

redis集群模式
  1. 主从模式 版本3以下出现

  2. 哨兵模式 版本5以下出现

  3. 去中心化模式 版本5之前python引入,5之后自带

主从模式

redis主从模式表示一个主节点若干个从节点

  1. 主节点可以负责写操作和读操作。

  2. 从节点只负责读操作。

  3. 主节点的数据会自动同步到所有的从节点上。

注意:
  1. 如果某台slave(从)宕机,恢复后继承主节点仍具有master新增的数据:从机重启恢复后默认为主机,重新选主变从之后才会继承主节点所有数据

  2. master(主)宕机后,slave(从)不会自动选举(主):意味着主机宕机后只能通过从机进行查找操作,无法进行增删改;

搭建redis主从模式
  1. 创建主从文件,拷贝redis.conf放入

    配置主从需要主从的IP或端口不同,并都启用

    若IP相同则:

    将配置文件中:

    6379全部改为新端口

    //端口号

    port 6379;改为新端口

    //启动显示端口号

    dbfilename dump.rdb;改为新端口dump6379.rdb(新端口)

    //附加文件名

    appendfilename "appendonly.aof";改为修改后的文件名(不同端口需要不同文件一个一个启动)

    //附加管理名

    appenddirname "appendonlydir";改为appendonlydir6379(新端口)

  2. 启动

    redis-server 配置文件名称.conf

  3. 配置主从关系

    进入IP:

    redis-cli -h 连接IP -p 端口

    配从不配主(默认即为主节点),

    从节点配置命令

    slaveof 主节点IP 主节点port(端口)

    查看主从的状态:

    info replication

哨兵模式
为了解决主从模式的缺陷:

当主节点宕机后,从节点无法直接上位。

搭建sentinel服务时,尽量搭建奇数个。

选举机制,通过哨兵投票制筛选继承者;

监控机制:

Sentinel基于心跳机制检测服务状态,每隔1秒向集群的每个实例发送ping命令;

  1. 主管下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线;

  2. 客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线,quorum值最好超过Sentinel实例数量的一半

选举机制:

一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据是:查看状态:info replication

  1. 首先会判断slave节点与master节点断开时间长短如果超过指定值(down-after-millisencods*10)则会排除该slave和节点

  2. 然后判断slave节点的slave-priority值,越小优先级越高,如果为0则永不参与选举

  3. 如果slavae-prority一样 则判断slave_rep_offset值,越大说明数据越新,优先级越高

  4. 最后判断slave节点的运行id大小,越小优先级越高;

使用:
  1. 修改sentinel.conf

    sentinel monitor 哨兵命名 IP 端口 哨兵数量

  1. 启动哨兵服务

    redis-sentinel sentinel.conf
  2. 出现+switch-master 命名 IP说明启动成功

去中心化模式
原理

redis 集群中内置了16384个哈希槽

当需要在 Redis 集群中放置一个 key-value时

redis 先对 key 使用 crc16 算法算出一个整数结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽

redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

当你往Redis Cluster中加入一个Key时,会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中,一个hash slot中会有很多key和value。你可以理解成表的分区,使用单节点时的redis时只有一个表,所有的key都放在这个表里;改用Redis Cluster以后会自动为你生成16384个分区表,你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区,每个分区里有很多key。

需求最少三台主机三台从机(主节点中不能有数据):

主从+哨兵模式,

  1. 多少个机器就需要多少个redis.conf,文件中:

    REDIS CLUSTER 标注下修改为:

    cluster-enabled yes

    cluster-config-file nodes-端口.conf

  2. 启动每个要启用的机器:

    redis-server 配置文件名称.conf

  3. 分槽,以及设置主从关系 redis-cli --cluster create --cluster-replicas 每个主机的从机数量 主机IP:主机端口 主机IP:主机端口 主机IP:主机端口 从机IP:从机端口 从机IP:从机端口 从机IP:从机端口

  4. 输入yes确定分配完成去中心化模式搭建;

命令行客户端:

redis-cli -c -h 进入的IP -p 端口


网站公告

今日签到

点亮在社区的每一天
去签到