RDB 虽然会把持久化的操作交给子进程，但每次都会从头开始，在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。
AOF 的优点：
AOF 使用追加的方式，每次写入时间很短，因此可以允许更短间隔的持久化操作，比如 1 秒。
AOF 文件的可读性比较好，如果你不小心执行了一条命令，只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件里的该条命令然后重启 Redis 即可。
AOF 的缺点：
对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
使用 fsync 会降低 Redis 的性能，导致 AOF 的速度可能会慢于 RDB 。
RDB 和 AOF 各有所长，RDB 体积小，恢复速度快，而且可以生成快照；AOF 频率更高，可以保存更新的数据。一般来说，推荐同时使用。
Redis 过期机制Redis 采取的是惰性删除和定期删除配合使用的方式。
惰性删除是指 Redis 会在访问某个键的时候检查该键是否过期，如果过期，就会将输入键从数据库中删除。但惰性删除不能及时清理内存，因此 Redis 还有定期删除的机制。
定期删除是另一种过期键删除方式。Redis 会维护一个过期字典（如下图所示），所有声明了过期时间的键都会被添加进这个字典中。周期操作函数 serverCron 执行时，会在规定时间内随机检查一部分键的过期时间，并删除其中的过期键。
RDB、AOF 和复制功能对过期键的处理 RDB 对过期键的处理RDB 文件在生成时会检查每个键的过期时间，过期键不会被添加进 RDB 文件里。
载入 RDB 文件时，如果该服务器是主服务器，则不会载入文件中过期的键；如果该服务器是从服务器，则不论过期与否都会被载入。不过，因为主从服务器在同步的时候，从服务器的数据库会被清空，所以一般来讲，过期键对载入 RDB 文件的从服务器不会造成影响。
AOF 对过期键的处理AOF 文件写入时，如果数据库中的某个键已过期，但它还没被删除，那么 AOF 文件不会因为这个键产生任何影响。当它被惰性删除或者定期删除之后，程序会向 AOF 文件追加一条 DEL 命令显示记录该键已被删除。
AOF 重写时，和生成 RDB 文件一样，会过滤掉已经过期的键。
复制功能对过期键的处理主服务器在删除一个过期键后，会显式地向所有从服务器发送一个 DEL 命令，告知从服务器删除这个过期键。
Redis 3.2 前，为了保持主从一致性，从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像处理未过期键一样处理过期键。从服务器只有在接到主服务器发来的 DEL 命令之后，才会删除过期键。Redis 3.2 后，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端。