四：持久化
redis支持RDB和AOF两种持久化机制，持久化有效避免了因程序退出造成的数据丢失问题。
1.RDB
将当前进程数据生成快照保存到硬盘的过程。
1）触发机制
* 手动触发 save|bgsave命令，触发命令使用如下
127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started5300:M 21 Jan 02:28:35.338 * DB saved on disk
5300:M 21 Jan 02:28:41.285 * Background saving started by pid 5305
5305:C 21 Jan 02:28:41.298 * DB saved on disk
5305:C 21 Jan 02:28:41.298 * RDB: 0 MB of memory used by copy-on-write
5300:M 21 Jan 02:28:41.304 * Background saving terminated with success
5300:M 21 Jan 02:29:24.592 * Background saving started by pid 5307
5307:C 21 Jan 02:29:24.594 * DB saved on disk
5307:C 21 Jan 02:29:24.595 * RDB: 0 MB of memory used by copy-on-write
5300:M 21 Jan 02:29:24.599 * Background saving terminated with success#save ""
save 900 1
save 300 10
save 60 10000
注意：save命令会阻塞当前redis服务，知道保存完成，对于内存较大的实例会造成长时间的阻塞；而bgsave则会执行fork操作创建子进程，持久化操作由子进程执行，阻塞只发生在fork阶段，一般时间很短。
2）RDB文件
通过设置redis.conf文件中的dbfilename和dir属性来确定文件路径和文件名称
dbfilename dump.rdb
dir ./
3）RDB优缺点
* 优点：是一个紧凑的二进制文件，代表某个时间点上的数据快照，适合用于备份；redis加载RDB恢复数据快于AOF的方式
* 缺点：无法做到实时持久化
2.AOF
以独立日志的方式记录每次写命令，重启时会重新执行AOF文件中的命令以达到恢复数据的目的
1）配置方式
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
通过配置redis.conf下的appendonly属性为yes；设置appendfilename；配置同步文件策略为everysec
2)AOF执行过程
* 所有写入命令追加到aof_buf缓冲区中
* aof缓冲根据对应的策略同步到硬盘
* aof文件越来越大时需要定期对aof文件做重写操作，以达到压缩的目的
* redis服务器重启时，加载aof文件进行数据恢复
3）文件同步策略
* always 命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回
* everysec 命令写入aof_buf后调用系统write操作，write操作完成后线程返回，fsync同步文件操作由专门线程每秒调用一次
* no 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步。
注意：默认选择的everysec策略为最优方案，兼具了性能和数据安全
4）重写机制
命令的不断写入导致aof文件越来越大，当超过一定大小后，redis会执行重写策略来压缩文件体积
重写是将redis中现有的数据转换为写命令同步到新的aof文件中的过程
重写如何压缩文件体积？
* 超时数据不再写入文件
* 原无效命令不再写入新文件
* 合并多条命令
触发方式？
* 手动触发 调用bgrewriteaof命令
* 自动触发 根据下面两个参数来确定重写时机，同时满足时则触发重写
auto-aof-rewrite-percentage 100 #代表当前aof文件空间和上一次重写后的aof文件空间比值
auto-aof-rewrite-min-size 64mb #运行aof文件重写时的文件最小体积
