内存中的数据具有易失性，为防止数据丢失，Redis有两种数据持久化机制：RDB与AOF。

# RDB

# RDB持久化简介

RDB指redis的快照储存方式（snapshotting）。进行rdb持久化时，redis会将所有数据序列化到一个rdb文件中（默认为dump.rdb），在下一次redis-server启动时，会自动加载文件中的数据，实现数据持久化。

rdb持久化可以通过显式命令save与bgsave执行：

save执行时会占用server主进程，此时server将拒绝其他client请求直到持久化完成，因此在生产环境中应尽量避免使用save方式进行rdb持久化；

bgsave会fork一个子进程执行rdbSave函数进行实际的快照存储工作，而父进程可以继续处理客户端请求。当子进程退出后，父进程调用相关回调函数进行后续处理。

另外，redis也可以通过配置文件的方式定时启动rdb持久化：

# redis.conf
# 表示如果60秒内写数据超过1000次，则执行rdb持久化
save 60 1000
1
2
3

# RDB持久化优缺点

优点：

  1. 对主进程无影响。RDB持久化由子进程完成，父进程无需任何磁盘IO操作，对服务无影响；
  2. 速度快。RDB文件的恢复比AOF文件要快；
  3. 便于储存和管理。RDB只生成一个文件，方便运维人员进行管理。

缺点：

  1. RDB持久化最主要的缺点就是可能会出现数据丢失的问题。由于RDB持久化有间隔时间，当间隔时间内发生宕机时，此部分数据便会丢失，因此RDB持久化适用于可以容忍部分数据丢失的场景；

  2. 另外，虽然RDB持久化过程对主进程没有影响。但是如果Redis内存数据过大，fork时复制内存的时间就会过长，也会造成服务暂时性无响应。

# AOF

# AOF简介

AOF全称是Append Only File，即追加文件持久化。

AOF持久化机制是将所有收到的写命令都记录在一个文件中（默认appendonly.aof），当redis-server重启时，就可以按照文件中的写命令一步一步还原redis数据。

AOF机制理论上不会丢失任何数据，但是由于IO写缓存的存在，如果恰巧某一条命令刚写入缓存区还未同步至文件时发生了崩溃，则会丢失此次数据。可以设置配置文件调整缓存同步频率（默认为1秒，可以调整为每次）。

# AOF优缺点

优点：

  1. 高可靠性。AOF持久化机制相比RDB更加可靠，即使是默认的文件同步频率依然保证了数据持久化的可靠性；
  2. 可读性。RDB持久化使用特定序列化方法储存数据，且采用二进制方式储存文件，文件不具备可读性；而AOF持久化记录的是每条写命令，运维人员可以直接读取AOF文件，进行数据维护工作。

缺点：

  1. 文件体积较大，且恢复速度缓慢；
  2. AOF在恢复过程可能存在一些bug，导致无法完全恢复数据，而RDB没有这种问题。