持久化操作 :
redis是一个内存数据库 , 当redis服务器重启 , 或者电脑重启的时候 , 这些数据就会丢失 ,
我们可以将redis内存中的数据持久化保存到硬盘的文件中 , 当redis服务器重新启动的时候 , 将数据重新加载进内存
redis持久化操作 , 并不能保证数据的安全性 , 只能保证大部分数据的安全 , 会造成数据的丢失
1.RDB : (默认方式 , 性能高 , 推荐)
- save : 由redis主进程来执行RDB , 会阻塞所有命令
- bgsave : 开启子线程执行RDB , 避免主进程收到影响
- 默认方式 , 不需要进行配置 , 默认使用就是这种机制
- 在一定的间隔时间中 , 检测key的变化情况 , 然后去持久化数据
- 对性能影响较小 (推荐使用)
- 持久化会将数据存放在运行目录下的一个以 rdb为后缀 的文件中
- 重新启动redis服务器 , 就会加载这个文件
配置 :
在redis的根目录下 , 找到 redis.windows.conf文件 : 找到这三行 这是基本的配置属性
-
- after 900 sec (15 min) if at least 1 key changed - 15分钟内至少有1个key改变 , 就会持久化 save 900 1 - after 300 sec (5 min) if at least 10 keys changed - 5分钟内至少有10个key改变 , 就会持久化 save 300 10 - after 60 sec if at least 10000 keys changed - 一分钟内至少有10000个key改变 , 就会持久化 save 60 10000
bgsave : 开始时会fork主进程 , 得到子进程 , 子进程共享主进程的内存数据 , 完成fork后读取内存数据并写入RDB文件
子进程是异步的进行存储数据 , 当正在拷贝的时候 , 主进程执行写操作了 , 这个时候 , 会完整复制这个要操作的数据的副本 , 对这个副本 进行写操作
注意 : 如果是在极端情况下 , 子进程进行拷贝的时候 , 主进程进行了大量的写操作 , 将所有的数据进行复制 , 这个时候 ,会占用双倍的内存 , 所以 , 在对redis指定内存的时候 , 不能一下将所有的空间都交给redis , 要保留一定的空间 , 否则就会造成内存溢出
RDB方式bgsave的基本流程 :
-
fork主进程得到一个子进程 , 共享内存空间
-
子进程读取内存数据 , 并写入新的RDB文件
-
用新的RDB文件替换旧的RDB文件
RDB会在什么时候执行 ? save 60 1000 代表什么含义 ?
- 默认是服务停止时
- 代表60秒内至少执行1000次修改则触发RDB
RDB的缺点 :
- RDB执行间隔时间长 , 如果系统宕机了 , 就会造成数据丢失
- fork子进程 , 压缩 , 写出RDB文件都比较耗时
2.AOF : (需要设置 , 性能低 , 不推荐)
全称 : Append Only File (追加文件)
- 日志记录的方式 , 可以记录每一条命令的操作 , 可以每一次命令操作后 , 来持久化数据
- 每修改保存一条数据 , 就持久化一次
- 对性能影响较大 (不推荐使用)
- 持久化会将数据存放在根目录下的一个以 appendonly.aof 为后缀 的文件中
配置 :
首先在 redis.windows.conf文件中找到
这里默认值是no , 也就是说 , 默认AOF是关闭的 , 如果想要使用 , 就要把这个值改为 yes
同时 : 还要设置下边的三个属性之一
# 表示每执行一次写命令 , 立即记录到AOF文件
# appendfsync always :
# 写命令执行完先放入AOF缓冲区 , 然后表示每隔1秒将缓冲区数据写到AOF文件 , 是默认方案
appendfsync everysec :
#写命令执行完先放入AOF缓冲区 , 由操作系统决定何时将缓冲区内容写回磁盘
# appendfsync no : 不进行持久化
重写AOF文件 :
使用AOF文件会比RDB文件大的多 , 而且AOF会记录对同一个key的多次写操作 , 但是只有最后一次写操作才有意义 , 通过指定bgrewriteaof , 命令 , 可以让aof文件执行重写功能 , 用最少量的命令达到相同的效果
Redis也会在触发阙值时自动去重写AOF文件 , 阙值也可以在redis.conf中配置
# AOF文件比上次文件 , 增长超过多少百分比则会触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才会触发重写
auto-aof-rewrite-min-size 64mb