Redis的各种机制

一、Redis的持久化机制

1.简介
Redis有两种持久化机制,分别是RDB和AOF,RDB:每个一段时间保存一个快照;AOF:保存每次写的操作指令;
2.RDB
(1)RDB的概念
RDB:每隔一段时间,把内存中的数据写入磁盘的临时文件,作为快照,恢复的时候把快照文件读进内存。如果宕机重启,那么内存里的数据肯定会没有的,因为RDB的存在,那么重启redis后,则会恢复。
(2)备份与恢复
备份:内存备份 --> 磁盘临时文件
恢复:磁盘临时文件 --> 恢复到内存
(3)RDB优劣势分析
优势
a. 每隔一段时间全量备份(快照)
b. 灾备简单,可以远程传输
c. 子进程备份的时候,主进程不会有任何io操作(不会有写入修改或删除),保证备份数据的的完整性
d. 相对AOF来说,当有更大文件的时候可以快速重启恢复
劣势
a发生故障是,有可能会丢失最后一次的备份数据
b.可能会造成CPU负担,因为子进程所占用的内存比会和父进程一模一样
c. 由于定时全量备份是重量级操作,所以对于实时备份,就无法处理了
(4)配置RDB持久化机制
修改redis.conf文件的关键信息

#快照文件名称
dbfilename "dump.rdb"
#redis工作目录,临时备份文件将会存在这个位置
dir "/usr/local/redis/working"
#至少发生了一次变化,会在900秒后保存
save 900 1 
#至少发生了10次变化,会在300秒后保存
save 300 10 
#至少发生了10000次变化,会在60秒后保存
save 60 10000
#如果save过程出错,是否停止写操作 yes:停止|no:不停止,一般使用yes
stop-writes-on-bgsave-error yes
#是否开启rdb压缩模式
rdbcompression yes
#压缩时,是否真的rdb进行校验
rdbchecksum yes

注意,如果使用RDB,可能会丢失最后一次备份的rdb文件,如果对于数据完整性关注度不高,可以忽略不计,如果数据完整性要求高,可以选择使用AOF持久化机制
3.AOF
(1)概念
a.以日志的形式来记录用户请求的写操作。只记录写操作
b. 文件以追加的形式而不是修改的形式
c. redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作
(2)RDB优劣势分析
优势
a. AOF更加精确,可以以秒级别为单位备份,如果发生问题,也只会丢失最后一秒的数据,大大增加了可靠性和数据完整性
b.当数据太大的时候,redis可以在后台自动重写aof。当redis继续把日志追加到老的文件中去时,重写也是非常安全的,不会影响到客户端的其他操作
c. AOF 日志包含的所有写操作,会更加便于redis的解析恢复
d.以log日志形式追加,如果磁盘满了,会执行 redis-check-aof 工具

劣势
a.同一份数据,AOF更占内存
b. 针对不同的同步机制,AOF会比RDB慢,因为AOF每秒都会备份做写操作,这样相对与RDB来说性能就略低
c.AOF发生过bug,就是数据恢复的时候数据不完整,这样显得AOF会比较脆弱,容易出现bug

(3)配置AOF持久化机制
修改redis.conf文件的关键信息

# AOF 默认关闭,yes可以开启 
appendonly no
# AOF 的文件名 
appendfilename "appendonly.aof"

#备份机制 no:不同步 | everysec:每秒备份,推荐使用 | always:每次操作都会备份,安全并且数据完整,但是慢性能差 
appendfsync everysec

# 重写的时候是否要同步,no可以保证数据安全 
no-appendfsync-on-rewrite no

# 重写机制:避免文件越来越大,会自动优化压缩指令,该机制会复刻一个新的进程去完成重写动作,新进程里的内存数据会被重写,此时 
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m,满足两者则触发重写 
auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb

二、Redis 内存淘汰机制与缓存过期处理

1.Redis 的内存淘汰机制
(1)概念
当内存占用满了以后,redis提供了一套缓存淘汰机制:MEMORY MANAGEMENT
(2)策略

#默认
maxmemory-policy noeviction

解释:
noeviction:旧缓存永不过期,新缓存设置不了,返回错误
allkeys-lru:清除最少用的旧缓存,然后保存新的缓存(推荐使用)
allkeys-random:在所有的缓存中随机删除(不推荐)
volatile-lru:在那些设置了expire过期时间的缓存中,清除最少用的旧缓存,然后保存新的缓存
volatile-random:在那些设置了expire过期时间的缓存中,随机删除缓存
volatile-ttl:在那些设置了expire过期时间的缓存中,删除即将过期的
2.Redis的缓存过期处理
(1)概念
Redis的高并发高性能都是基于内存的,但是内存都是有限的,并且内存越大的服务器越贵。
(2)设置了expire的key缓存过期了,但是服务器的内存还是会被占用,这是与redis的缓存过期删除策略有关
a.定时随机的检查过期的key,如果过期则清理删除。(每秒检查次数在redis.conf中的hz配置)
b.当客户端请求一个已经过期的key的时候,那么redis会检查这个key是否过期,如果过期了,则删除,然后返回一个nil。这种策略对CPU比较友好,惰性删除,基本不会损耗CPU,但是内存占用会比较高。

当然,Redis是使用了这两种机制相结合的形式来进行过期处理的,对于内存占用情况还是有不错的改善。

三、redis的主从机制

1. 单节点分析
一般情况而言,单节点并发可以达到几万,如果运维人员对优化做的足够好,也最多不会超过20万,所以当并发量上来后,可以考虑使用主从模式;
2.主从模式概念
主从模式,也是读写分离模式,主节点负责写数据,并且将新的数据同步到从节点,而从节点负责读数据。主从模式,属于水平扩展,通过增加服务器节点的方式来提高并发量。使用主从模式,如果在从节点上写数据,这里会提示错误,因为从节点只负责读取数据。
在这里插入图片描述
3.主从原理
在这里插入图片描述
(1)初始化
从节点(slave)初次启动时会向主节点(master)发送ping包,在发送ping包后,主节点会把数据全量的同步到从节点。
(2)后续写操作
主节点每一次触发写操作,都会将指令同步给从节点,以此来修改从节点相应的数据
(3)slave宕机重启
slave宕机重启后,master会把slave宕机的这段时间的数据增量的同步给slave
(4)主从模式,master必须开启持久化
主从模式下,如果master没有开启持久话,那么一旦宕机,master再次重启时,所有数据都将会丢失,包括从节点的数据。
4.配置主从模式
(1)修改从节点配置文件redis.conf
a.进入配置目录

#配置文件目录根据实际情况而定
cd /usr/local/redis

b.搜索配置目标

/replica

在这里插入图片描述
c.配置内容

#主节点信息
replicaof 192.168.1.2 6379
#主节点密码
masterauth root
#配置从节点为只读
replica-read-only yes

注:
如果不知道redis使用的配置文件在哪里,可以使用find / -name redis_init_script 检查启动文件中关联的配置文件在哪里
查找启动文件
在这里插入图片描述
查看关联的配置文件
在这里插入图片描述

四、redis的哨兵机制

1.意义
Master挂了,继续保证可用性,实现继续读写

2.概念
Sentinel(哨兵)是用于监控Redis集群中Master状态的工具,是 Redis 高可用解决方案,哨兵可以监视一个或者多个redis master服务,以及这些master服务的所有从服务。当某个master服务宕机后,会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。
3.配置主节点
(1)拷贝redis解压目录下的sentinel.conf文件到/usr/local/redis/目录

#进入解压目录
cd /home/software/redis-5.0.8
#拷贝文件
cp sentinel.conf /usr/local/redis/

(2)修改sentinel.conf文件

cd /usr/local/redis/
vim sentinel.conf

(3)配置内容

普通配置:
这里只展示修改过的配置,其他默认

#是否开启保护模式,注意节点没有在公网上使用no,在公网上需要改为yes,且需要配置bind
protected-mode no
#哨兵是否在后台运行
daemonize yes
#日志文件
logfile /usr/local/redis/sentinel/redis-sentinel.log
#工作目录
dir /usr/local/redis/sentinel

核心配置
这里只展示可能需要修改的内容,其他默认

# 配置哨兵 
sentinel monitor mymaster 127.0.0.1 6379 2 
# 密码 
sentinel auth-pass <master-name> <password> 
# master被sentinel认定为失效的间隔时间 
sentinel down-after-milliseconds mymaster 30000 
# 剩余的slaves重新和新的master做同步的并行个数 
sentinel parallel-syncs mymaster 1 
# 主备切换的超时时间,哨兵要去做故障转移,这个时候哨兵也是一个进程,如果他没有去执行,超过这个时间后,会由其他哨兵接替当前哨兵的工作
sentinel failover-timeout mymaster 180000

4.配置从节点
(1)将主节点的sentinel.conf文件远程拷贝到从节点

 scp sentinel.conf root@192.168.1.7:/usr/local/redis/

(2)检查从节点sentinel.conf文件是否有误

more sentinel.conf | grep ^[^#]

5.启动-主节点
(1)启动主节点哨兵

redis-sentinel sentinel.conf

(2)查看进程

ps -ef|grep redis

在这里插入图片描述

(3)查看启动日志

cd /usr/local/redis/sentinel/
tail -f redis-sentinel.log 

6.启动-从节点
(1)启动

 redis-sentinel sentinel.conf

(2)打开客户端,检查主从是否配置错误

redis-cli
auth root
info replication

7.原Master恢复后很有可能出现不同步的问题
(1)现象
当master宕机后,再次重启恢复,此时该节点的角色从主节点转换为从节点,在该节点的客户端中通过指令info replication查看节点信息,如果看到主节点的状态为 master_link_status:down,则说明当前节点的redis核心配置文件(redis.conf)没有配置masterauth
(2)解决
修改redis核心配置文件(redis.conf)

#主节点密码
masterauth root

(3)其他可能造成master数据无法同步给slave的原因
a. 网络通信问题,要保证互相ping通,内网互通
b. 关闭防火墙,对应的端口开发(虚拟机中建议永久关闭防火墙,云服务器的话需要保证内网互通)
c.统一所有的密码(masterauth),不要漏了某个节点没有设置

8.哨兵信息检查

# 查看mymaster下的master节点信息 
sentinel master mymaster 
# 查看mymaster 下的slaves节点信息 
sentinel slaves mymaster  
# 查看mymaster 下的哨兵节点信息 
sentinel sentinels mymaster 

五、Redis-Cluster 集群

1.经典模式
三主三从,经典模式
在这里插入图片描述
2.环境准备
准备6台redis单节点服务器,尽量不要使用配置过其他模式的redis节点,避免出现异常情况。如果一定要用,记得还原配置,主要是redis.conf

3.构建Redis集群
(1)redis.conf 配置

# 开启集群模式 
cluster-enabled yes 
# 每一个节点需要有一个配置文件,需要6份。每个节点处于集群的角色都需要告知其他所有节点,彼此知道,这个文件用于存储集 
cluster-config-file nodes-201.conf 
# 超时时间,超时则认为master宕机,随后主备切换 
cluster-node-timeout 5000 
# 开启AOF 
appendonly yes

(2)删除原有备份文件

#进入redis.conf 中的dir配置的目录下,具体路径视个人情况而定
cd /usr/local/redis/working
#删除RDB备份文件
rm dump.rdb -f
#删除aof备份文件
rm appendonly.aof -f

(3)启动6个redis实例
a.启动6台
b. 如果启动过程出错,把rdb等文件删除清空
(4)创建集群

##### 
# 注意1:如果你使用的是redis3.x版本,需要使用redis-trib.rb来构建集群,最新版使用C语言来构建了,这个要注意 # 注意2:以下为新版的redis构建方式 
##### # 创建集群,主节点和从节点比例为1(--cluster-replicas 1),1-3为主,4-6为从,1和4,2和5,3和6分别对应为主从关系。这也是redis集群中最经典的一种
redis-cli -a root --cluster create ip1:port1 ip2:port2 ip3:port3 ip4:port4 ip5:port5 ip6:port6 --cluster-replicas 1

按回车后,会提示是否可以设置时,请输入yes
注意:使用redis-cli --cluster指令可以查看集群指令管理。
slots:槽,用于装数据,主节点有,从节点没有
(5)检查集群信息

redis-cli -a root --cluster check ip:port

(6)进入集群控制台

redis-cli -c -a root -h ip -p port
#在集群控制台中,查看集群信息
cluster info
#在集群控制台中,查看节点信息
nodes info

如果没有密码,就不需要使用额外附加指令-a root

4.关于槽节点
(1)槽(slot)节点分配
在这里插入图片描述
特点:均等分配,只要master上才有槽节点
(2)槽怎么存储
hash(key)%16384(总槽节点)

©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页