Redis持久化

43fdw

  Redis是一个开源的高性能键值存储数据库。之所以性能优异，是因为Redis是把所有的数据都存在内存中的。这样会有一个问题：当服务器重启或程序异常崩溃时，Redis的数据就会全部丢失。虽然生产环境中，Redis仅被用于缓存，但是如果能够对其数据做持久化的操作，还是一个不错的选择。
    Redis默认支持两种持久话的方式，分别是基于快照形成的RDB文件和基于命令操作存储的AOF文件，接下来笔者就对两种持久化方式做简单的介绍。



1.RDB（默认开启）
    RDB实际上是通过快照来完成持久化操作的，当符合一定条件后，Redis会自动的把内存中的数据写入磁盘。可以通过配置文件中的save选项来设置同步策略。

1 2	save 300 10     #代表300s内有10个键值改动就触发数据落地操作。多行save是或的策略。 save ""         #设置不进行数据持久化（只写入这一行save）

同样，也可以手动执行SAVE和BGSAVE命令就行持久化。不同之处在于，前者是Redis主进程进行快照，后者是fock子进程进行快照。Redis默认写入RDB文件名为dump.rdb，会存在当前目录。可以通过配置文件的dir和dbfilename执行目录和文件名。

1 2 3 4

rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data/redis/8001/data

Redis RDB方式的快照过程如下：
1.redis父进程利用fock函数生成一个子进程
2.父进程继续接收并处理客户端发来的命令，子进程则将内存中的数据写入硬盘，暂时先写入临时文件。对于正在写入的数据，操作系统会使用写时复制的策略，即复制一份该片数据保证子进程的落地数据不被修改。
3.当数据写完时，子进程会用临时文件替代现有的RDB文件，这样一次快照就顺利的完成了。
缺点：
使用RDB方式进行持久化有个缺点，就是一旦程序异常退出而不再最后一次触发快照的那一刻，Redis最后一次快照之后的数据会丢失。

2.AOF（默认未开启）
    AOF实际上存储的是纯文本文件，其内容是Redis客户端和服务器通信的原始数据记录。具体文件大家可以编辑appendonly.aof文件查看。
AOF文件重写：
使用AOF方式进行数据落地会有一个问题，因为保存的是每次操作命令的过程，可能存在数据冗余。Redis也提供了相关的机制可以对落地文件行进重写，比如对一个变量进行多次赋值操作，重写之后只会保存最后一次的键值。重写过程也有一定的触发条件，默认设置如下：

1 2 3 4

appendonly yes        #打开AOF存储方式（当文件很小时，可能数据会有较多冗余） appendfilename appendonly.aof     #设置AOF存储文件名字 auto-aof-rewrite-percentage 100   #当AOF文件超过上一次重写时大小的百分之多少时开始重写 auto-aof-rewrite-min-size 64mb    #限制允许重写的最小AOF文件大小

重写操作也可以在客户端手动执行命令BGREWRITEAOF触发。重写的过程先在内存中完成，之后再写入磁盘文件。过程类似于RDB文件落地方式。
由于操作系统由于操作系统的缓存机制，实际上每次文件落地并没有真正的写入硬盘，而是写入磁盘的缓存文件。默认操作系统每隔30s会写一次数据。但是当系统异常退出还是会有数据丢失，所以开启AOF的redis需要设置操作系统缓存落地时间，默认/s。详细设置选项如下：

1 2 3

#appendfsync always               #always表示每个命令都执行落地 appendfsync everysec              #everysec表示每s执行一次 #appendfsync no                   #no不主动同步，交给操作系统执行，默认30s

备注：当同时开启RDB和AOF方式的持久化，Redis会选择AOF方式。因为该方式可能丢失的数据更少。但是时间较RDB恢复方式慢！