数据持久化就是将内存中的数据存储到磁盘上的过程，实现持久化有两种方式：
- 快照模式(snapshot)：在某一时刻将所有数据进行一个整体的备份，例如mysql的dump模式，redis的RDB模式
- 日志类型(log type)：所有的写操作(增、删、改)都会备份到一个文件中，当需要恢复数据的时候，所有的备份命令会被重新执行一次，例如mysql的binlog，redis的AOF操作
redis持久化是将内存数据存储到硬盘里的一种操作，它同样提供了两种不同的持久化方法，分别是：
一、快照(snapshotting，RDB redis database): 将某一时刻的内存数据全部存储到磁盘中。快照是一个rdb文件，是由子进程创建的，并且新的快照文件会覆盖旧的快照文件，涉及到快照类型的持久化命令有：
save <seconds> <changes>：如果seconds秒内有changes次的变化，则触发持久化操作
save 900 1: 300秒内有1次插入操作，则进行持久化操作
save 300 10: 300秒内有10次插入操作，则进行持久化操作
save会导致阻塞情况的产生，save期间redis服务会停止响应客户端的请求，这时可使用bgsave模式，利用后台进程完成数据存储。
其他的配置信息有：
# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /home/work/app/redis/data/
# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes：备份进程出错时，主进程停止接受新的写入操作
# 是否压缩
rdbcompression yes：设置为yes时，redis会压缩存储到磁盘上的快照文件，会消耗一部分CPU时间，可以设置为no，则
# 导入时是否检查
rdbchecksum yes：默认yes,可对存储后的快照使用CRC64算法来进行数据校验，会消耗性能，如果希望获取性能提升，可设置为false
RDB持久化的优势：
- RDB文件是一个非常紧凑的文件，它保存了某一时间点的数据，所以允许你恢复不同的版本数据
- RDB很适合数据恢复，作为单个的压缩文件，rdb文件可以很容易地传递到其他数据中心
- RDB性能损耗小，redis主进程用于启动子线程，由子进程完成IO操作，也就是将数据存储到磁盘上，主线程不进行IO操作
- 相比较AOF，RDB恢复大数据集时的速度较快
RDB持久化的优势：
- 对于紧急系统的失败，RDB持久化是不推荐使用的， 系统如果发生以外失败，则在下次要执行备份操作之前的最近一段时间的数据将会丢失
- 降低CPU性能，RDB备份是由子进程执行的，如果数据量大的话，主进程在进行fork()操作的时候可能耗时较多，在创建子进程的时候，redis会响应请求，AOF也需要执行fork()操作，但是频率不是那么高，并且你也可以调整重写日志的频率
二、只追加文件(Append-Only File,AOF): redis服务每次接收到写操作(增、删、改)时都会将这种操作实时地追加到日志文件(AOF file)中，当redis重启动时，redis引擎重新执行AOF文件中的命令来重构数据集；AOF持久化有3中策略：
- always模式：每次执行一条命令，缓存都会被更新且命令会被追加到AOF文件中，相比其他模式，该模式速度慢、IO操作频繁，但是安全性非常高
- Everysec(default & recommended)：缓存每秒刷新一次以将命令追加到AOF文件中，该模式速度快且只可能丢失一秒内的数据信息
- no：不执行缓存刷新操作，由操作系统决定什么时候同步数据，该模式速度最快，但是也最不安全
AOF重写：AOF操作是向文件中持续追加命令的过程，随着写命令的增加，AOF文件会越来越大。但是许多命令会覆盖旧值(例如：incr)，这样是的保存旧的命令不是必须的。因此redis在不打断服务的情况下可以重构AOF文件，手动执行bgrewriteaof命令，redis会创建一个新的后台进程，该后台进程生成一个新的AOF文件，该新文件只会包含构建当前数据集所需的最少命令；bgrewriteaof可设置为异步执行，即使该命令执行失败数据也不会丢失，因为旧的AOF文件是不会被修改的。AOF重写有两个好处：1、降低磁盘的使用，2、恢复数据更快，因为命令的执行被优化了，去掉了不必要的操作。
AOF的配置：
#Enable AOF persistence 开启AOF模式 appendonly yes #Aof persistent file name 指定AOF的文件名 appendfilename appendonly-<port>.aof #Synchronizes buffer data to disk per second 每秒一次，将缓存中的数据同步到磁盘 appendfsync everysec #Data persistence file storage directory 指定存放位置 dir /var/lib/redis #Do you want to unsynchronize data to AOF files when rewriting 重写时开启异步模式，如果设置为no的话，则是同步模式 #Yes means that the data is not synchronized to the AOF file when rewriting，if you have latency problem,turn this to yes
#otherwise leave is as "no" that is the safest pick from the point of view of durability no-appendfsync-on-rewrite no #Minimum size to trigger rewriting of AOF file 触发重写操作的最小文件大写条件 auto-aof-rewrite-min-size 64mb #File volume growth rate that triggers AOF file rewriting 目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时进行重写
#如果之前没有重写，则以启动时的aof文件大小为依据，同时还要求aof文件的大小至少要大于 auto-aof-rewrite-min-size设定的值 auto-aof-rewrite-percentage 100
这里有一个关键性设置"no-appendfsync-on-rewrite no",有必要在这里好好总结一下：
当appendonly设置为yes时，redis会触发linux fsync()函数，告诉操作系统立马把数据写到磁盘上，而不是等着输出缓存达到一定的数据量才将数据写到磁盘上，刚才讲了AOF持久化的3种策略，就是fsync的3种执行策略，其实每次执行fsync()函数的时候也可能会阻塞的(例如：写磁盘的操作也会产生竞争导致阻塞情况的发生)，主进程和后台进程在进行数据保存的时候会产生冲突，no-appendfsync-on-rewrite参数设置为yes的时候，当其他的子进程正在进行保存操作的时候(saving)，redis的持久化策略相当于"appendfsync no"，就是上面讲的缓存数据何时写道磁盘交由操作系统去决定，一般情况下是30秒一次写缓存操作，所以如果发生意外，可能造成30s内数据的丢失，所以如果系统延迟性没太大问题时，no-appendfsync-on-rewrite应设置为no.
AOF持久化的优势：
- 使用AOF策略时，redis数据的保存连续性更强，你可以调整不同的保存策略来选择符合你的操作
- AOF日志是一个只追加类型的日志，没有查询(seek)操作，没有停电时的崩溃操作，即使在某种情况下，日志以一个半写(half-written)命令结尾，redis-check-aof工具也能够很容易地恢复它
- AOF包含了所有了保持顺序的操作命令，这些命令容易理解和解析，你可以很容易地输出一个AOF文件，例如如果你意外地执行了一个FLUSHALL命令，与此同时日志的rewrite的操作并未执行，你也可以通过停止服务器来保存数据，删除最后一条命令(FLUSHALL)，然后重启redis
AOF持久化的缺点：
- AOF文件要比RDB文件大很多，因为它实时地将所有的操作命令都保存了下来
- 在执行fysnc策略的时候，AOF要比RDB慢
Redis7.0以前的版本还有以下问题：
- AOF使用更多的内存空间
- 在执行rewrite操作的时候，所有的write命令会写到磁盘种两次
- 在rewrite操作结束时，redis会冻结写操作，并将这些写命令同步到一个新的AOF文件中去
RDB+AOF:两种持久化策略都使用，在这种情况下，当redis重启时，AOF文件会被用于重构原来的数据集，因为它的备份更为完整。
建议：如果你想要获取一定程度的数据安全性，你可以同时使用这两种持久化策略；如果你更关心数据但是也能容忍一定程度的数据丢失，你可以只选择RDB模式；许多用户会只使用AOF，但是这种策略是不鼓励的，因为不定期的获取RDB快照对于数据库的备份和更快地恢复数据是一个很好的选择。
redis未来的长期规划是将AOF模式和RDB模式合并未一个持久化模型，或许那时候我们不用纠结于选择了，redis已经为我们提供好最优的数据持久化方法，期待那一天的到来......
