1、Redis.config详解
-
单位
-
包含
-
网络
bind 127.0.0.1 #绑定的ip
protected-mode yes #保护模式
port 6379 #端口设置
-
日志
-
通用
daemonize yes #以守护进程的方式运行,默认是 no
pidfile /var/run/redis_6379.pid #以后台的方式运行,需要指定一个pid文件
logfile "" #日志的文件位置名
databases 16 #数据库的数量,默认是16个数据库
- 快照
持久化,在规定时间内执行了多少次操作,则会持久化到文件 .rdb .aof中
redis是内存数据库,如果没有持久化,那么数据就会断电即失
save 900 1 #如果在900s内有1个key进行了修改,就会进行持久化操作
save 300 10 #如果在300s内有10个key进行了修改,就会进行持久化操作
save 60 10000 #如果在60s内有10000个key进行了修改,就会进行持久化操作
rdbcompression yes #是否压缩rdb文件,需要消耗一些cpu资源
rdbchecksum yes #保存rdb文件的时候,进行错误的检查校验
dir ./ # rdb文件保存的目录
-
安全
-
APPEND ONLY MODE----aof配置
appendonly no #默认是不开启aof模式的,默认是使用rdb方式持久化的,在大部分情况下,rdb完全够用
appendfilename "appendonly.aof" #持久化的文件的名字
# appendfsync always #每次修改都sync,消耗性能
appendfsync everysec #每秒执行一次sync,可能会丢失这1s的数据
# appendfsync no #不执行sync,操作系统自己同步数据,速度最快
2、Redis持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失,所以redis提供了持久化功能。
2.1、RDB(Redis DataBase)
-
在指定的时间间隔内将内存中的数据集体快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读入内存中。
-
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化之后的数据可能丢失。
-
rdb保存的文件是 dump.rdb
触发机制
- save规则满足的条件下,会自动触发rdb保存
- 执行flushall命令,也会触发rdb保存
- 退出redis服务器时也会生成一个rdb文件
恢复RDB文件
- 只需要将rdb文件放在我们redis启动目录就可以,redis启动时会自动检查dump.rdb恢复其中的数据
- 查看需要存放rdb文件的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "D:\\Java\\redis64" #如果在这个目录下存在dump.rdb文件,启动就会自动恢复其中的数据
2.2、AOF(Append Only File)
将我们的所有命令都记录下来,相当于history,恢复的时候就把这个文件全部再执行一遍!
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初就会读取该文件重新构建数据,换言之,redis重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF保存的是appendonly.aof文件
如果这个aof文件有错误,这个时候redis是启动不起来的,我们需要修复这个aof文件
redis给我们提供了一个工具 redis-check-aof
使用命令 redis-check-aof --fix appendonly.aof 就可以修复
3、Redis发布订阅
4、Redis主从复制
4.1、概念
主从复制,是指将一台Redis服务器的数据,复制到其他Redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单项的,只能由主节点到从节点。Master以写为主,Slave以读为主。
一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不可能的(宕机),原因如下:
- 从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求,压力较大;
- 从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器的内存容量为256G,也不能将所有的内存用作Redis缓存。一般来说,单台Redis最大使用内存不应该超过20G。
主从复制,读写分离!80%的情况下都是在进行读操作,架构中经常使用一主二从减缓服务器压力!
4.2、环境配置
只配置从库,不用配置主库!
复制3个配置文件,然后修改对应的信息
- 端口号
- pid 名字
- log 文件名字
- dump.rdb名字
4.3、一主二从
默认情况下,每台Redis服务器都是主节点,只用配置从机。
从机的信息:
主机的信息:
主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动的被从机保存!
Master接到命令,启动后台的存盘进程,同时收集所有接受到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,并完成一次完全同步。
5、哨兵模式
5.1、概念
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,他会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
哨兵的作用:
- 通过发送命令,让Redis服务器返回其运行状态,包括主服务器和从服务器。‘
- 当哨兵检测到master宕机,可以自动将slave切换为master,通过发布订阅模式通知其他从服务器,修改配置文件,从而切换主机。
一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此使用多个哨兵进行监控,形成多哨兵模式。
5.2、测试
-
编写哨兵配置文件sentinel.conf
sentinel monitor myredis 127.0.0.1 6379 1 #sentinel monitor 被监控的名称 host port 1
后面这个数值1代表主机挂了,slave投票选择主机
-
启动哨兵
-
如果Master节点断开了,就会从从机中随机选择一个服务器
并且如果主机此时回来了,只能归并到新的主机下,当作从机。
6、Redis缓存穿透和雪崩(面试高频,工作常用~!)
6.1、缓存穿透(查不到)
6.1.1、概念
当用户想要查询一个数据,发现Redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中,于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这就是缓存穿透。
6.1.2、布隆过滤器
布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;
6.1.3、缓存空对象
当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据结构将会从缓存中获取,保护了后端数据源;
6.2、缓存击穿(缓存过期,过量访问)
6.2.1、概念
-
当一个key非常热点,在不停的扛着大并发,大并发集中对这个点进行访问,当这个key失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开一个洞。
-
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并回写缓存,导致数据库瞬间压力过大。
6.2.2、解决方案
-
设置热点数据永不过期
-
加互斥锁
分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获取分布式锁的权限,因此只需要等待即可。将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
6.3、缓存雪崩
6.3.1、概念
缓存雪崩是指在某一个时间段,缓存集中过期失效。Redis宕机。
6.3.2、解决方案
-
Redis高可用:搭建集群
-
限流降级:缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量
-
数据预热:手动加载缓存不同的key,设置不同的过期时间,让缓存失效的时间尽量均匀