一、Redis持久化
Redis之所以强大是因为其将所有数据都直接存储在内存中。可是，为了使Redis在重启后数据仍然不丢失，就需要把数据以某种方式持久化到磁盘中（这是使用它作系统缓存的一大优势）。Redis支持两种方式进行持久化，一种是RDB，一种是AOF,可以使用一种方式，也可以混合使用它们两种方式。
二、RDB方式（默认的持久化方式）
2.1 RDB方式简介
其实是通过snapshot快照的方式进行持久化的，当符合一定条件时，Redis会自动将内存中的所有数据快照存储到磁盘中。进行快照的配置文件在配置文件中指定（redis.conf）,有两个参数构成：时间和在这个间隔时间内改动的键的个数，当在指定时间内被更改的键的个数大于配置中指定值时就会进行快照持久化。
在配置文件中已经预置了3个条件：（以下条件关系是“或”）
#15分钟内至少有1个键被更改
#5分钟内至少有10个键被更改
#1分钟内至少有10000个键被更改
2.2 rdb文件
# The filename where to dump the DB
dbfilename dump.rdb
# 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 ./
如上图中，RDB数据存储文件默认文件是dump.db,位置默认也是在当前文件夹的
2.3 RDB数据恢复过程
Redis启动后会读取RDB快照文件，将数据从磁盘载入内存中，一般情况下，1GB的快照文件载入到内存的时间为20~30秒。
2.4 快照过程
RDB的快照过程：
1. 当快照条件满足时，Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
2. 父进程继续接收并处理客户端发来的命令，而子进程则将内存中的数据写入磁盘的临时文件；
3. 当子进程写入完所有数据后会用该临时文件替换旧有的RDB文件。
2.5 手动快照
如果没有触发自动快照，需要对Redis进行手动快照操作，SAVE和BGSAVE都是手动快照命令，但二者有区别：
SAVE执行快照，是由主进程进行快照，会阻塞其他请求，而BGSAVE是子进程进行快照。
2.6 快照需要注意事项
由于Redis使用fork复制了一份进程，那么子进程就会占有和父进程一样的内存资源，比如说父进程8G内存，那么备份的时候必须保证有16G内存，要不然会启用虚拟内存（swap）,性能非常差。
2.7 RDB文件的压缩
RDB文件默认是通过压缩的，可以同过配置文件rdbcompression参数来配置。
压缩和不压缩的优缺点：
压缩：
优点：减少磁盘存储空间
缺点：消耗CPU资源
不压缩：
优点：不消耗CPU资源
缺点：占用磁盘空间多
具体配置如下：
# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
三、AOF方式
3.1 AOF简介
AOF持久化策略是将发送到Redis服务端的每条命令都记录下来保存到磁盘当的AOF文件中，AOF文件的名称和位置都可以在配置文件中配置
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
appendonly yes （开启AOF持久化策略）
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
3.2 AOF实例
当Redis向服务端发送Redis命令时，Redis会将所执行的命令记录到AOF文件当中，如下：
SELECT
$1
1
*3
$3
SET
$5
test2
$22
this is my fight song!
*2
$6
SELECT
$1
0
*3
$3
SET
$3
123
$18
first line is null
Redis重启将会执行该文件
3.3 优化AOF文件
使用BGREWRITEAOF命令来重写AOF文件。这样可以去除中间执行过程，保留最终命令即可。
3.4 重写策略
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
重写策略的参数设置：
auto-aof-rewrite-percentage 100
当前的AOF文件大小超过上一次重写时的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。
auto-aof-rewrite-min-size 64mb
限制了允许重写的最小AOF文件的大小，通常在AOF文件很小的时候即使其中有些冗余的命令也是可以忽略的。
3.5 文件同步策略
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
文件写入默认情况下会先写入到系统的缓存中，系统每30秒同步一次，才是真正的写入磁盘，如果30秒服务器宕机拿数据也是会丢失的，Redis可以通过配置参数修改同步策略。
appendfsync always 每次接收命令都立马同步（最安全，也最缓慢）
appendfsync everysec 每秒同步 （默认同步策略）
appendfsync no 不主动同步，有操作系统来决定（最不安全，但是最快）
注意：即使每秒做文件同步也可能导致数据丢失。
