内存型数据库Redis持久化小结

因为redis是内存型数据库，所以为了防止因为系统崩溃等原因导致数据丢失的问题，redis提供了两种不同的持久化方法来将数据存储在硬盘里面，一种方法是快照（rdb），它可以将存在于某一个时刻的所有数据都写入到硬盘里面，另外一种方法是只追加文件（aof），它会在执行写命令时，将被执行的写命令都写入到硬盘里面。

快照持久化

redis可以通过创建快照来获得在内存里面的数据在某一个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其它服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。

有两个命令可以用于生成rdb文件，一个是save，另外一个bgsave。

在只使用快照持久化来保存数据时，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序。

save

特点：save命令会阻塞redis服务器进程，直到rdb文件创建完毕，在服务器进程阻塞期间，服务器不能处理任何命令请求。

缺点：服务器持久化期间无法接受其它请求。

bgsave

特点：bgsave命令则会派生出一个子进程，然后由子进程负责创建rdb文件，服务器进程则继续处理命令请求。

缺点：创建子进程所耗费的时间会随着redis占用的内存而增加。

aof持久化

aof持久化会将被执行的写命令写到aof文件的末尾，以此来纪录数据所发生的变化，因此，redis只要从头到尾重新执行一次aof文件所包含的所有写命令，就可以恢复aof文件所记录的数据集。

在设置同步频率的时候，存在三个选项：

选项	同步频率
always	每个redis写命令都要同步写入硬盘，但是这样做会占用redis所拥有的内存，严重降低redis的速度
everysec	每秒执行一次同步，显式地将多个写命令同步到硬盘
no	让操作系统来决定应该何时进行同步

最好使用everysec，既能避免每次都写入所造成的性能影响，又能避免操作系统崩溃所导致的可能丢失不定量数据，其即使系统崩溃，用户最多只会丢失一秒之内产生的数据，当硬盘忙于执行写入操作的时候，redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

缺点：因为redis会不断的将被执行的写命令纪录到aof文件里面，所以随着redis不断执行，aof文件的体积也会不断增长，极端条件下，aof甚至可能会用完硬盘的所有可用空间。

为了解决上面的缺点，redis提供了bgrewriteaof命令，这个命令会通过移除aof文件中的冗余命令来重写aof文件，使得aof文件尽可能的小。它的原理和bgsave命令相似，redis会创建一个子进程，然后由子进程负责对aof文件进行重写，因为aof文件重写也需要用到子进程，所以同样存在快照持久化因为创建子进程所导致的性能问题和内存占用问题。