redis是一个内存数据库，一旦断电或服务器进程退出，内存数据库中的数据将全部丢失，所以需要redis持久化 redis持久化就是把数据保存在磁盘上，利用永久性存储介质将数据保存，在特定的时间将保存的数据进行恢复的工作机制
RDB:存储数据结果，关注点在数据
AOF:存储操作过程，关注点在数据的操作过程
在指定的时间间隔内将内存中的数据集写入磁盘，也就是快照(Snapshot),数据恢复是将快照文件直接读到内存中
redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入一个到一个临时文件(dump.rdb)中,待持久化过程结束后，再用本次的临时文件替换上次持久化后的文件。
fork函数的作用是复制一个与当前进程一样的进程，新进程的所有数据数值都和原进程一致，但是一个全新的进程，并作为原进程的子进程。
redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但创建子进程是同步阻塞的，此时不接受其他请求。
手动触发：通过命令手动生成快照
自动触发：通过配置参数的设置触发自动生成快照
1.手动触发
执行save和bgsave命令，手动触发快照，生成RDB文件
save: 该命令会阻塞当前redis服务器，执行save命令期间，redis不能处理其他命令，直到RDB过程结束为止(会造成长时间阻塞，不建议使用)
bgsave:该命令执行后，redis会在后台异步进行快照操作，快照同时还可以响应客户端的请求，阻塞只发生在fork阶段，基本上redis内部的所有RDB操作都是采用bgsave命令
2.自动触发
redis.conf配置文件中达到save参数的条件，自动触发bgsave
主从复制时，从节点要从主节点进行全量复制时也会触发bgsave,生成快照发送到从节点
执行shutdown(关闭redis服务)，会触发bgsave
执行flushall(生成一个空的临时文件dump.rdb)
将备份文件(dump.rdb)移动到redis路径下(可以配置文件的存放路径)启动服务即可，redis启动会将文件数据加载到内存，在此期间redis会处于阻塞状态，直到全部数据存入内存。
优点：
数据恢复快
体积小
数据备份使用子进程，对redis服务性能影响小
缺点：
在一定时间间隔进行备份，当redis意外宕机，将会丢失最后一次修改的数据，无法做到秒级持久化
fork进程时，会占用一定的内存空间
RDB文件是二进制的没有可读性
将客户端的每一个写操作命令以日志的形式记录下来，追加到appendonly.aof的文件末尾，在redis服务器重启时，会加载aof文件中的所有命令，来达到数据恢复的目的
当有写命令请求时，会追加到AOF缓冲区内，AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中，当AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写来压缩AOF文件容量，redis服务重启时，会重新加载AOF文件中的写操作来进行数据恢复
1.手动触发
通过bgrewriteaof命令：重新AOF持久化生成aof文件(触发重写)
2.自动触发
默认情况，redis是没有开启AOF(默认使用RDB持久化)，需要通过配置文件开启
always: 把每个写命令立即同步到AOF文件，很慢但安全
everysec: 每秒同步一次，默认配置
no: redis不执行写入磁盘，交给OS系统处理，很快但不安全
AOF持久化，会把每次写命令都追加到appendonly.aof文件中，当文件过大，redis的数据恢复时间就会变长，因此加入重写策略对aof文件进行重写，生成一个恢复当前数据的最少命令集。
eg: 比如对同一个key进行多次写命令 set key 5 incr key incrby key 500 重写后就变为 set key 506
手动触发可以使用bgrewriteaof命令
自动触发通过配置文件配置
主进程fork出一个子进程进行AOF文件的重写，子进程重写完毕后，主进程把子进程重写期间，其他客户端产生的写请求，追加到AOF文件中，替换旧文件
AOF的rewirte重写和RDB的bgsave都是由父进程fork出一个子进程来执行的
重写是直接把当前内存的数据生成对应的命令，而不是读取旧AOF文件进行命令合并
优点：
数据安全性高，不易丢数据
AOF文件有序保存了所有写操作，可读性强
缺点：
AOF方式生成文件体积大
数据恢复速度比RDB慢
原文链接: https://www.yukx.com/xiaomengbao/article/details/2367.html 优科学习网redis的两种持久化方式
