Redis 持久化（AOF和RDB）

Redis支持RDB和AOP两种持久化方式，持久化功能有效避免了因进程推出导致数据丢失问题，在下一次redis重启之后可以根据之前持久化文件来恢复数据。
注意：不建议用redis来做数据存储，如果用redis做存储，必然会有大量的数据数据进入到内存里面，造成内存的浪费，个人认为利用redis做缓存，分布式的一些功能是比较可取的。

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，每隔一段时间把rdb文件删了，再把数据刷到硬盘生成新的rdb。触发RDB持久化过程分为手动触发和自动触发。
注意：这种持久化方式也会造成部分数据丢失

手动触发

• save 阻塞当前redis服务器，直到RDB过程完成为止，对于内存较大redis实例会造成长时间阻塞，线上环境不建议使用

192.168.10.151:7777> save
OK

• bgsave 会创建一个fork子进程（如果已经有fork子进程，直接返回），持久化操作通过fork子进程完成，阻塞只发生在创建fork子进程阶段，一般时间很短

192.168.10.151:7777> bgsave
Background saving started

很显然，bgsave比save好很多，bgsave是save的优化，redis内部所有涉及RDB的操作都使用bgsave，save方式虽然没有废弃，但是已经不建议使用了。

自动触发

• 配置redis.conf, 意思是m秒内，执行n次修改后，自动触发bgsave

save m n

获取相关配置

192.168.10.151:7777> config get save
1) "save"
2) "900 1 300 10 60 10000"

• 如果从节点执行全量复制操作，主节点自动执行bgsave生成RBD文件并发送给从节点。

• 执行debug reload重新家在redis时，也会自动触发save操作

192.168.10.151:7777> debug reload
OK

• 默认情况下，执行shuntdown，如果没有开启AOF持久化功能，则自动执行bgsave

AOF

append only file的缩写，以独立日志的方式记录每次的写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的（重演一遍文件中的命令）。AOF的主要作用时解决了数据持久化的实时性，目前已经是Redis持久化的主流方式，此功能对于数据安全极为重要。

开启

默认不开启，appendonly=yes 为开启，通过config set appendonly yes开启，通过config get dir*来查看redis保存的路径，rdb和AOF共用一个目录。

192.168.10.151:7777> config set appendonly yes
OK
192.168.10.151:7777> config get append*
1) "appendonly"
2) "yes"
192.168.10.151:7777> config get dir*
1) "dir"
2) "/data/redis/data"

文件同步

AOF缓冲区同步文件策略，由参数appendfsync控制

192.168.10.151:7777> config get appendfsync
1) "appendfsync"
2) "everysec"

可配置的参数有：

• always
• everysec
• no