Redis是内存型数据库，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。  Redis 持久化方式  1.RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照 2.AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。  RDB  在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。  可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。  这种持久化方式被称为快照（snapshot）。  RDB工作机制  当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：     Redis 调用 fork() ，同时拥有父进程和子进程。   子进程将数据集写入到一个临时 RDB 文件中。   当子进程完成对新 RDB文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。    这样的好处就是可以 copy-on-write。  RDB的优点     RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份。   RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑。    RDB的缺点  1.如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 2.每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；  AOF持久化  AOF 持久化，每一个写命令都通过write函数追加到 appendonly.aof 中。              选项     同步频率                   always     每个写命令都同步             everysec     每秒同步一次             no     让操作系统来决定何时同步          always 选项会严重减低服务器的性能；everysec 选项比较合适，可以保证系统奔溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；no 选项并不能给服务器性能带来多大的提升，而且也会增加系统奔溃时数据丢失的数量。  AOF工作机制     Redis 执行 fork() ，现在同时拥有父进程和子进程。   子进程开始将新 AOF 文件的内容写入到临时文件。   对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。   当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。   Redis 用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。