聊聊Redis的持久化
两种持久化策略
1.AOF：记录每一次的写操作到日志上，重启时重放日志以重建数据
2.RDB：每隔一段时间保存一次当前时间点上的数据快照
快照就是一次又一次地从头开始创造一切
3.可以关闭持久化
4.在持久化上、AOF好一些，但AOF依然存在不如RDB的地方
AOF
优点
多种策略可以选择：是每秒同步一次（默认，灾难发生会丢失1秒的数据）、还是每次请求时同步一次（超级慢 + 超级安全）、从不执行同步。
日志使用追加模式；当日志太大时Redis会重新创建一个日志写
重写日志是安全的，Redis一边会在旧的日志上追加，一边会创建新的日志文件，一旦新日志创建完毕，就往新文件上追加
缺点
AOF文件显然占据大量存储空间
举例：对count = 1累加100次，最终的结果是count对应的值只会有一个，就是100；但是AOF文件里面却有100条记录
当你恢复的时候他会超级费时的重复这些操作（浪费！）
AOF比RDB慢，有延迟
bug比RDB多
AOF文件损坏后就麻烦了，redis-check-aof --fix命令用于修复
RDB
优点
对于每个一段时间要保存一下数据特别适用。如：每隔24小时保存一次数据
可以保存不同时间点的rdb（通过复制备份，看下文），然后你可以恢复不同时间点的数据库
由于保存的是整个库，所以恢复大数据集特别快
启动子进程来处理RDB文件的写入
缺点
在时间间隔内挂掉的话数据会丢失，要做好一定会丢失数据的准备
RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒
选择谁
如果可以接受丢失几分钟的数据，选择RDB吧！
如何配置
配置RDB
默认开启RDB
在redis.conf文件里面可以看到RDB策略
################################ SNAPSHOTTING ################################
#Save the DB on disk:
#save
#Will save the DB if both the given number of seconds and the given
#number of write operations against the DB occurred.
#In the example below the behaviour will be to save:
#after 900 sec (15 min) if at least 1 key changed
#after 300 sec (5 min) if at least 10 keys changed
#after 60 sec if at least 10000 keys changed
#Note: you can disable saving completely by commenting out all "save" lines.
#It is also possible to remove all the previously configured save
#points by adding a save directive with a single empty string argument
#like in the following example:
#save ""
save 900 1
save 300 10
save 60 10000
#By default Redis will stop accepting writes if RDB snapshots are enabled
#(at least one save point) and the latest background save failed.
#This will make the user aware (in a hard way) that data is not persisting
#on disk properly, otherwise chances are that no one will notice and some
#disaster will happen.
#If the background saving process will start working again Redis will
#automatically allow writes again.
#However if you have setup your proper monitoring of the Redis server
#and persistence, you may want to disable this feature so that Redis will
#continue to work as usual even if there are problems with disk,
#permissions, and so forth.
stop-writes-on-bgsave-error yes
##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
#Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
#This makes the format more resistant to corruption but there is a performance
#hit to pay (around 10%) when saving and loading RDB files, so you can disable it
#for maximum performances.
#RDB files created with checksum disabled have a checksum of zero that will
#tell the loading code to skip the check.
rdbchecksum yes
#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 ./
翻译一下
################################ 快照 #################################
Save the DB on disk:保存数据库到磁盘
save <秒> <更新>
如果指定的秒数和数据库写操作次数都满足了就将数据库保存。
下面是保存操作的实例：
900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
注释：注释掉“save”这一行配置项就可以让保存数据库功能失效。
你也可以通过增加一个只有一个空字符串的配置项（如下面的实例）来去掉前面的“save”配置。
save ""
save 900 1
save 300 10
save 60 10000
#在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。
#如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。
#然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。
stop-writes-on-bgsave-error yes
#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？
#默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。
#如果你想在存储的子进程中节省一些CPU就设置成'no'，
#但是这样如果你的kye/value是可压缩的，你的到处数据接就会很大。
rdbcompression yes
#从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。
#这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，
#所以，为了达到性能的最大化，你可以关掉这个配置项。
#没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查。
rdbchecksum yes
#导出数据库的文件名称
dbfilename dump.rdb
#工作目录
#导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。
#只增的文件也会在这个目录创建（这句话没看明白）
##注意你一定要在这个配置一个工作目录，而不是文件名称。
dir ./
#配置AOF（我就直接上翻译后的配置文件了）
############################## APPEND ONLY MODE ###############################
#是否开启AOF，默认关闭（no）
appendonly yes
#指定 AOF 文件名
appendfilename appendonly.aof
#Redis支持三种不同的刷写模式：
appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no
no-appendfsync-on-rewrite no
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb
如何工作的
每当 Redis 需要转储数据集到磁盘时，会发生：
Redis 调用 fork()。于是我们有了父子两个进程。
子进程开始将数据集写入一个临时 RDB / AOF 文件。
当子进程完成了新 RDB 文件，替换掉旧文件。
AOF的fork（），与RDB不同的是父进程会在一个内存缓冲区中积累新的变更，同时将新的变更写入旧的 AOF 文件，所以即使重写失败我们也安全。当子进程完成重写文件，父进程收到一个信号，追加内存缓冲区到子进程创建的文件末尾，接着自动重命名旧文件为新的，然后开始追加新数据到新文件
这个方法可以让 Redis 获益于写时复制(copy-on-write)机制。
备份数据（或者叫灾难恢复吧）
Redis运行时可以拷贝rdb文件，不可以拷贝aof
可以每隔一段时间复制一份rdb文件到安全区域并以时间点命名，这样可以根据时间点恢复数据库
