介绍一下redis的两种持久化方式rdb和aof
我们看redis目录下经常看到有.rdb和.aof后缀的文件，这两种文件都是redis持久化数据文件，但是持久化模式不相同，rdb持久化模式生成的数据文件为.rdb后缀的文件，而aof模式产生的数据文件为.aof后缀的文件。那么我们来详细介绍一下rdb和aof持久化模式。
rdb
rdb持久化模式也称为快照持久化。rdb持久化是通过fork（复制）主进程，产生一个子进程的形式来将内存中的数据持久化。
为什是fork一个主进程？
1.redis是单线程的。
2.redis为了保证读写性能，于是持久化使用新的子进程来进行io操作，这样能保证redis主进程的性能。
rdb持久化触发方式
-
手动触发，rdb持久化可以通过手动触发来进行，触发方式有bgsave和save两种，这两种方式的区别是bgsave不会阻塞主进程而save会。
我们对redis使用save命令触发redis进行持久化，在执行save命令前后分别查看dump.rdb文件的更新时间，从上图看出执行save命令后dump.rdb文件发生来改变。
此时我们使用redis客户端向redis执行一个set命令写入一个key，由于save命令触发持久化主线程会被阻塞，此时set命令不会立即得到返回。需要等到持久化完成才能得到set的返回。若我们使用bgsave触发持久化，同时向redis执行一个set命令，会立即得到返回，证明bgsavae命令不会阻塞主线程。 -
退出redis时触发持久化。 退出是指使用shutdown命令退出redis，而不是使用kill杀掉redis进程，kill不会触发redis进行持久化。
-
间隔一定时间自动触发持久化。
rdb持久化的优缺点
rdb模式的优点
- rdb为二进制数据，占用内存小。
- 对灾难恢复更为有效，可以更快的传输。
- 每次都是fork一个子进程来进行io操作，保证来主线程的性能。
rdb的缺点
- 由于只能间隔一定时间触发持久化，面对redis挂掉的异常将丢失更多的数据。
aof
aof是将用户的所有操作都记录保存在aof文件中进行持久化。redis会对用户进行的所有写操作基于自身的aof协议写入aof文件。写入时间间隔小，最小支持1s写入。 当然，为了保证aof文件的大小，redis拥有对aof文件的瘦身机制。简单举例如用户对key1进行了100次+1操作，key1的初始值为0。在未触发aof文件瘦身时，按照aof模式规则，aof文件中存储了用户对key1对100次+1语句，触发aof瘦身后，瘦身完毕的aof对key1的记录只有一条set key1 100.当然aof文件内容当然不是简单的这样，需要符合redis的aof协议，这里只是简单的表达一下。 aof瘦身触发机制：当aof文件达到一定大小时触发瘦身，在redis config配置文件中对aof有两个配置值，一个是触发瘦身大小上限，另外一个是比例。例如文件大小为60G，文件比例为80%。即当文件达到60G时瘦身后文件减小为20G，那么下一次触发瘦身的文件大小为20+60*0.8=68G。以此类推。
aof的优点 aof的保存用户时间间隔小，理论上最小间隔为1s，当redis出现问题，能大大减小redis丢失的数据量。当然越小的间隔同时也面临着性能的消耗。一般会将aof的触发时间间隔根据实际情况做相应的调整。
rdb与aof的加载顺序
总结一下redis加载顺序：
- 当AOF和RDB文件同时存在时，优先加载AOF文件
- 若关闭了AOF，则加载RDB文件
- 加载AOF/RDB文件成功，Redis启动成功。AOF/RDB文件加载存在错误，启动失败，打印错误信息。
