redis使用日志（3）：如何设置持久化

Redis 持久化

Redis虽然是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。

工做目录(redis持久化存储的目录)：RDB 和 AOF 公用该目录

 

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /data/spider/Redis_Backup/   #能够自定义你的目录，默认为当前目录 dir ./

 

RDB持久化（redis 默认开启的）

redis提供了RDB持久化的功能，这个功能能够将redis在内存中的的状态保存到硬盘中，它能够手动执行，也能够再redis.conf中配置，按期执行。

RDB持久化产生的RDB文件是一个通过压缩的二进制文件，这个文件被保存在硬盘中，redis能够经过这个文件还原数据库当时的状态。

RDB的建立与载入

RDB文件能够经过两个命令来生成：

• SAVE：阻塞redis的服务器进程，直到RDB文件被建立完毕。
• BGSAVE：派生(fork)一个子进程来建立新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的建立以后，会发送信号给父进程，而与此同时，父进程处理命令的同时，经过轮询来接收子进程的信号。

而RDB文件的载入通常状况是自动的，redis服务器启动的时候，redis服务器再启动的时候若是检测到RDB文件的存在，那么redis会自动载入这个文件。

若是服务器开启了AOF持久化，那么服务器会优先使用AOF文件来还原数据库状态。

RDB是经过保存键值对来记录数据库状态的，采用copy on write的模式，每次都是全量的备份。

自动保存间隔

BGSAVE能够在不阻塞主进程的状况下完成数据的备份。能够经过redis.conf中设置多个自动保存条件，只要有一个条件被知足，服务器就会执行BGSAVE命令。

# 如下配置表示的条件：
# 服务器在900秒以内被修改了1次
save 900 1
# 服务器在300秒以内被修改了10次
save 300 10
# 服务器在60秒以内被修改了10000次
save 60 10000

AOF持久化（默认是关闭的）

AOF持久化（Append-Only-File），与RDB持久化不一样，AOF持久化是经过保存Redis服务器锁执行的写状态来记录数据库的。

具体来讲，RDB持久化至关于备份数据库状态，而AOF持久化是备份数据库接收到的命令，全部被写入AOF的命令都是以redis的协议格式来保存的。

在AOF持久化的文件中，数据库会记录下全部变动数据库状态的命令，除了指定数据库的select命令，其余的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。

服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：

• always：将缓存区的内容老是即时写到AOF文件中。
• everysec：将缓存区的内容每隔一秒写入AOF文件中。
• no ：写入AOF文件中的操做由操做系统决定，通常而言为了提升效率，操做系统会等待缓存区被填满，才会开始同步数据到磁盘。

redis默认实用的是everysec。

redis在载入AOF文件的时候，会建立一个虚拟的client，把AOF中每一条命令都执行一遍，最终还原回数据库的状态，它的载入也是自动的。在RDB和AOF备份文件都有的状况下，redis会优先载入AOF备份文件

AOF文件可能会随着服务器运行的时间愈来愈大，能够利用AOF重写的功能，来控制AOF文件的大小。AOF重写功能会首先读取数据库中现有的键值对状态，而后根据类型使用一条命令来替代前的键值对多条命令。

AOF重写功能有大量写入操做，因此redis才用子进程来处理AOF重写。这里带来一个新的问题，因为处理从新的是子进程，这样意味着若是主线程的数据在此时被修改，备份的数据和主库的数据将会有不一致的状况发生。所以redis还设置了一个AOF重写缓冲区，这个缓冲区在子进程被建立开始以后开始使用，这个期间，全部的命令会被存两份，一份在AOF缓存空间，一份在AOF重写缓冲区，当AOF重写完成以后，子进程发送信号给主进程，通知主进程将AOF重写缓冲区的内容添加到AOF文件中。

相关配置

#AOF 和 RDB 持久化方式能够同时启动而且无冲突。  
#若是AOF开启，启动redis时会加载aof文件，这些文件可以提供更好的保证。 
appendonly yes   #默认为no，开启AOF持久化的时候，须要设置为yes

# 只增文件的文件名称。（默认是appendonly.aof）  
# appendfilename appendonly.aof 
#redis支持三种不一样的写入方式：  
#  
# no:不调用，之等待操做系统来清空缓冲区当操做系统要输出数据时。很快。  
# always: 每次更新数据都写入仅增日志文件。慢，可是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec  

# 设置为yes表示rewrite期间对新写操做不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议若是你有特殊的状况能够配置为'yes'。可是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no  

# 自动重写只增文件。  
# redis能够自动盲从的调用‘BGREWRITEAOF’来重写日志文件，若是日志文件增加了指定的百分比。  
# 当前AOF文件大小是上第二天志重写获得AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100  
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时因为文件尺寸较小致使频繁的重写。
auto-aof-rewrite-min-size 64mb

对比

• AOF更安全，可将数据及时同步到文件中，但须要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。
• RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。

建议：二者都打开，同时用两种方式持久化