Redis持久化

Redis持久化有两种方式：RDB和AOF

RDB

1，save指令
配置
设置数据存储文件的名称：dbfilename dump.rdb （通常设置为dump-端口号.rdb）
设置储存文件的路径：dir /data
设置储存至本地数据库时是否压缩：rdbcompression yes
是否进行格式校验：rdbchecksum yes 默认开启，如果不开启会节约读写过程时间消耗，但是储存一定的数据损坏风险

2，bgsave指令
手动启动后台保存操作，但是不立即执行，启动一个fork子进程进行数据持久化
后台存储过程中如果出现错误是否停止保存操作：stop-writes-on-bgsave-error yes 默认开启

3，save配置
满足限定范围内key的变化数量达到指定数量即进行持久化：save second changes
1，对数据产生影响
2，真正产生了影响，get不会，set、del会
3，不进行数据比对
注意：
save配置时要根据实际业务情况来配，频度过高或者过低都会出现性能问题，结果可能是灾难性的，
save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
save配置后执行的是bgsave操作

 

RDB的特殊启动形式
全量复制：
服务器运行中重启：debug reload
关闭服务器时指定保存数据：shutdown save

优点：

紧凑压缩的二进制文件，存储效率高
内部存储的时redis在某个时间点的数据快照，非常适合数据备份，全量复制等场景
数据恢复的速度比AOF快得多
应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中去，用于灾难恢复

缺点：

RDB无论时执行指令还是利用配置，无法做到实时持久化，具有较大的可行数据丢失。
bgsave指令每次运行要执行fork操作创建子进程，要牺牲一些性能
Redis众多版本中未进行RDB格式的版本统一，有可能出现各个版本服务之间数据格式无法兼容情况
 

AOF

以独立日志的方式记录每次写命令，重启时再执行AOF文件中命令达到恢复数据的目的，与RDB相比可以简单描述为：改记录数据为记录数据的产生过程
aof主要是为了解决数据持久化的实时性，目前已经是Redis持久化的主流方式

三种策略

1、always（每次）：每次操作均同步到AOF文件中，数据零误差，性能较低
2、everysec（每秒）：每秒将缓存区中的指令同步到AOF文件中，数据准确性较高，性能较高，系统宕机下丢失一秒的数据
3、no（系统控制）：由操作系统控制每次同步到AOF文件的周期，操作过程不可控。

配置：

是否开启AOF持久化功能，默认不开启：appendonly yes|no
AOF写数据的策略：appendfsync always|everysec|no
AOF持久化文件名：appendfilename filename
持久化文件的保存路径：dir /data

AOF重写

随着命令的不断写入，aof的文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF重写是将redis进程内的数据转化为写命令同步到新AOF文件的过程，简单的说就是将对一个数据的若干条指令执行结果转化成最终结果数据对应的指令进行记录。比如多条set指令只用记录最后一条。

重写规则：
1、进程内已超时的数据不在写入文件
2、忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只能保留最终数据的写入命令。
      如：del key1，hdel key2，srem key3，set key4 222.set key4 111等
3、对一条数据的多谢命令合并为一条命令
     如lpush list a,lpush list b,lpush list c可转化为：lpush list a b c
     防止客户端缓冲区溢出，list，set等类型每条最多写入64个元素

手动重写方式：
指令：bgrewriteaof
自动重写配置：
auto-aof-rewrite-min-size size 
auto-aof-rewrite-percentage percentage
自动重写触法对比参数：
aof_current_size
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和RDB的区别

持久化方式	RDB	AOF
占用存储空间	小	大
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失	依据策略
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

 

 

 

 

 

 

 

 

如何选择呢？

对数据非常敏感，建议使用默认的AOF持久化方案
数据呈现阶段有效性，建议使用RDB持久化方案
综合对比：
两种方式实际上再做一种权衡，每种都有利有弊
如果不能接受分钟以内的数据丢失，对业务数据比较敏感，选用AOF
追求大数据集的恢复速度，选用RDB
灾难性恢复选用RDB
双保险策略，同时开启RDB和AOF，重启后，Redis优先使用AOF来恢复数据，降低丢失数据的量