Redis的持久化取舍和选择
持久化的作用
什么是持久化
redis所有的数据都是保存在内存中，对数据的更新将异步的保存在磁盘中，如果数据没有持久到硬盘中，当redis服务器重启，redis数据将会丢失
RDB
什么是RDB
- RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
RDB触发机制 -- 主要三种
- save (同步)
save命令：阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，先上环境不建议使用
127.0.0.1:6379> save
OK文件策略 ：如存在老的 RDB文件 ，新老替换
时间复杂度 ： O(n)
- bgsave (异步)
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一段时间很短
文件策略 ：如存在老的 RDB文件 ，新老替换
时间复杂度 ： O(n)
- 自动触发 （Redis默认RDB持久化方式）
保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir {newDir} 和 config set dbfilename {newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression {yes|no}动态修改。
校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：
Short read or OOM loading DB. Unrecoverable error , aborting now.
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告
127.0.0.1:6379> bgsave
Background saving startedRDB总结
- RDB是Redis内存到硬盘的快照，用于持久化。
- save 通常会阻Redis
- bgsave 不会阻塞Redis，但会fork新经常
- save 自动配置满足任意条件就会执行
优点
- Redis加载RDB恢复数据远远快于AOF方式。
- RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
缺点
- 耗时、耗性能，RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
- RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB笨笨，存在老版本Redis服务无法兼容新版RDB格式的问题。
如何恢复
自动恢复：自动读取dump.rdb文件恢复 将备份文件移动到redis安装目录并启动服务即可。 CONFIG GET dir获取目录
注意：对dump.rdb文件进行备份 执行cp命令
cp dump.rdb dumo_new.rdb
AOF
什么是AOF
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
AOF 三种策略
- always
- everysec
- no
操作系统决定的
3者对比
重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是吧Redis进程内的数据转化为写命令同步到新AOF文件的过程。
作用
- 减少硬盘占用量
- 加快恢复速度
重写的2种方式
- bgrewriteaof
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
- aof 重写配置
根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB
auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值
自动触发时机=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
其中aof_current_size和aof_base_size可以再info Persistence统计信息中查看。
AOF重写流程
配置
//开启aof
appendonly yes
//aof日志
appendfilename "appendonly-${port}.aof"
//aof 持久化策略
appendsync eneeyec
//目录
dir /bigdiskpath
//重写的内容配置
//增长率
auto-aof-rewrite-percentage 100
//尺寸
auto-aof-rewrite-min-size 64mb
恢复数据
1. 设置appendonly yes；
2. 将appendonly.aof放到dir参数指定的目录；
3. 启动Redis，Redis会自动加载appendonly.aof文件。优缺点
AOF 的优点
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积
RDB和AOF的选择
RDB 和 AOF比较
RDB 和 AOF ,我应该用哪一个？
一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能，RDB
当作备份来处理，AOF主要用来恢复数据
