redis持久化方式，RDB,AOF

（1）RDB，把当前进程数据生成快照保存到硬盘的过程，有手动触发和自动触发

手动触发：

实现方式：save ，bgsave

save命令是同步的，对于特别大的数据和访问量大的 网站都会发生阻塞

bgsave命令是异步的，不会发生阻塞，该命令会执行fork操作创建子进程，RDB持久化由子进程负责，阻塞只发生在fork  阶段，redis的RDB操作主要用到bgsave

bgsave的流程：

1) 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如只RDB/AOF子进程，
如果存在bgsave命令直接返回。
2) 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork以操作的耗时，单位为微秒。
3) 父进程仍fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，
可以继续响应其他命令。
4) 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。
执行lastsave命令可以获取最后一次生成尺RDB的时间，对应info统计的rdb_last_save_time选项。
5) 进程发送信号给父进程衣示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

RDB非常适合用于做备份，全量复制但是无法做实时持久化

 

AOF，使用日志记录每次写命令，重启执行AOF文件命令达到恢复数据的目的，可做数据的实时持久化，是redis持久化的主流方式

开启AOF功能需要设置配置：appendonly yes,默认不开启。AOF文件通过appendfilename 配置设置，
默认文件名是appendonly.aof。保存路径同RDB持久化方式一致。通过dir配置指定

流程如下：

1） 所有的写入命令会追加到aof_buf（缓冲区）中。
2） AOF缓冲区根据对应的策略向硬盘做同步操作。
3） 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4） 当Redis服务重启时，可以加载AOF文件进行数据恢复。了解AOF工作流程之后，
下面针对每个步骤做详细介绍。

重写机制：

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。
AOF文件重写是吧Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为什么可以变下？有如下原因：
1） 进程内已经超时的数据不再写文件。
2）旧的AOF文件含有无效命令，如del key1、 hdel key2、srem keys、set a 111、set a 222等。
重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
3) 多条写命令可以合并为一个，如lpush list a、lpush list b、 lpush list c 可以转化为：
lpush list a b c。为了防止但挑明了过大造成客户端缓冲区溢出，对于list、set、hash、
zset等类型曹组，以64个元素为界拆分为多条。 
AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。
AOF重写过程可以手动触发和自动触发：

手动触发：直接调用bgrewriteaof命令
自动触发：更具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）的值