redis持久化
为什么redis需要持久化
- Redis是一个内存数据库，如果没有配置持久化，redis 重启后数据就全丢失 因此开启redis的持久化功能，将数据保存到磁盘上， 当redis重启后，可以从磁盘中恢复数据。
持久化方式
Rdb持久化
-
简介：在指定的时间间隔内将内存中的数据集快照写入磁盘（全量复制）
-
策略
-
save
- 会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
-
bgsave
- fork创建子进程，RDB持久化过程由子进程负责，会在后台异步进行快照操作，快照同时还可以响应客户端请求
-
自动化
- 配置触发Redis的RDB持久化条件，比如 “save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（在主从架构服务器同步数据的时候，会发送sync执行同步操作，master主服务器就会执行bgsave）
-
-
优点
- RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
- 在恢复大数据集时的速度比 AOF 的恢复速度要快
- 生成的是一个紧凑压缩的二进制文件
-
缺点
- 每次快照是一次全量备份，fork子进程进行后台操作，子进程存在开销
- 在快照持久化期间修改的数据不会被保存，可能丢失数据
-
核心配置
#任何ip可以访问 bind 0.0.0.0
#守护进程 daemonize yes
#密码 requirepass ******
#日志文件 logfile "/usr/local/redis/log/redis.log"
#持久化文件名称 dbfilename ***.rdb
#持久化文件存储路径 dir /usr/local/redis/data
#持久化策略, 10秒内有个1个key改动，执行快照
save 10 1
#导出rdb数据库文件压缩字符串和对象,默认是yes，会浪费CPU但是节省空间
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
- Linux内存分配策略
0 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存，内存申请允许;否则，内存申请失败，并把错误返回给应用进程
1 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2 表示内核允许分配超过所有物理内存和交换空间总和的内存
解决方式
echo 1 > /proc/sys/vm/overcommit_memory
持久化配置
vim /etc/sysctl.conf
改为
vm.overcommit_memory=1 修改sysctl.conf后，需要执行 sysctl -p 以使生效。
AOF持久化
-
简介：
- 追加文件的方式，文件容易被人读懂。
- 以独立日志的方式记录每次写命令， 重启时再重新执行 AOF文件中的命令达到恢复数据的目的。
- 写入过程宕机，也不影响之前的数据，可以通过 redis-check-aof检查修复问题。
- 默认不开启（设置appendonly yes开启）
- AOF文件名 通过 appendfilename 配置设置，默认文件名是appendonly.aof
- 存储路径同 RDB持久化方式一致，使用dir配置
-
原理
- Redis每次写入命令会追加到aof_buf(缓冲区)
- AOF缓冲区根据对应的策略向硬盘做同步操作
- 高频AOF会带来影响，特别是每次刷盘
-
策略
-
appendfsync always
- 每次有数据修改发生时都会写入AOF文件，消耗性能多
-
appendfsync everysec
- 每秒钟同步一次，该策略为AOF的缺省策略
-
appendfsync no
- 不主从同步，由操作系统自动调度刷磁盘，性能是最好的，但是最不安全
-
-
核心配置
bind 0.0.0.0
daemonize yes
requirepass ******
logfile "/usr/local/redis/log/redis.log"
dbfilename ******
dir /usr/local/redis/data
rdbcompression yes
#save 10 2
#save 100 5
#关闭rdb save ""
#对rdb数据进行校验，耗费CPU资源，默认为yes rdbchecksum yes
#是否开启aof
appendonly yes
#文件名称
appendfilename "appendonly.aof"
#同步策略
appendfsync everysec
AOF的rewrite重写
-
原因：
- AOF文件越来越大，需要定期对AOF文件进行重写达到压缩
- 旧的AOF文件含有无效命令会被忽略，保留最新的数据命令
- 多条写命令可以合并为一个
- AOF重写降低了文件占用空间
- 更小的AOF 文件可以更快地被Redis加载
-
策略
- 手动触发
- 调用bgrewriteaof命令
- 自动触发
- auto-aof-rewrite-min-size和auto-aof-rewrite- percentage参数
- auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。
- auto-aof-rewrite-percentage代表当前AOF文件空间和上一次重写后AOF文件空间(aof_base_size)的比值。
- auto-aof-rewrite-min-size和auto-aof-rewrite- percentage参数
- 手动触发
-
配置
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100
# 加载aof时如果有错如何处理
# yes表示如果aof尾部文件出问题，写log记录并继续执行。 no表示提示写入等待修复后写入
aof-load-truncated yes
AOF+Rdb（混合模式）
-
简介：
- 直接将rdb持久化的方式来操作将二进制内容覆盖到aof 文件中,rdb是二进制，所以很小
- 有写入的话还是继续append追加到文件原始命令，等下次文件过大的时候再次rewrite
- 默认是开启状态
-
优点
- 混合持久化结合了RDB持久化和 AOF 持久化的优点：采取了rdb的文件小易于灾难恢复；同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。
-
缺点
- 前部分是RDB格式，是二进制，所以阅读性较差
-
数据恢复
- 先看是否存在aof文件，若存在则先按照aof文件恢 复，aof比rdb全，且aof文件也rewrite成rdb二进制格式
- 若aof不存在，查找rdb是否存在