目录
对于redis的基本命令就不记录了，有需要的朋友可以查看以下文档。
命令参考资料:
http://www.runoob.com/redis/redis-tutorial.html
1.RDB
1.1 RDB简介
RDB（Redis DataBase）：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件读到内存中。Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。Redis默认使用RDB持久化。
1.2 RDB配置
~]# cat etc/redis.conf | grep "^###"
...
################################ SNAPSHOTTING ################################
save 900 1 #15分钟内改了1次
save 300 10 #5分钟内改了10次
save 60 10000 #1分钟内改了1万次，如上条件满足其一会将数据写入磁盘，禁用rdb持久化 save "" 即可。
stop-writes-on-bgsave-error yes #默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，
#这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，否则就会没人注意到灾难的发生。
#如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。
#然而你要是安装了靠谱的监控，你可能不希望 redis这样做。
#如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制。
rdbcompression yes #对于存储到磁盘中的快照，可以设置是否进行压缩存储。
#如果是的话，redis会采用LZF算法进行压缩。
#如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum yes #在存储快照后，还可以让redis使用CRC64算法来进行数据校验，
#但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
dbfilename dump.rdb #生成的快照文件名称
dir ./ #数据库备份的文件放置的路径 .rdb .aof
#路径跟文件名分开配置是因为Redis备份时，先会将当前数据库的状态写入到一个临时文件。
#等备份完成时，再把该临时文件替换为上面所指定的文件
#而临时文件和上面所配置的备份文件都会放在这个指定的路径当中默认值为 ./
...1.3 显示启动快照保存机制
客户端显示使用save或bgsave命令来手动启动快照保存机制：
SAVE：阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。
BGSAVE：非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。
1.4 RDB优缺点
优点：
- RDB是一个非常紧凑的文件。
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
- 与AOF相比，在恢复大数据集的时候，RDB方式会更快一些。
缺点：
- 数据丢失风险大
- RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级不能响应客户端请求。
2.AOF
2.1 AOF简介
AOF（Append Only File）：以日志的形式来记录每个写操作，将Redis执行过程的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2.2 AOF配置
~]# cat etc/redis.conf | grep "^###"
...
################################ APPEND ONLY MODE ################################
appendonly no #AOF持久化是否启动默认为关闭
appendfilename "appendonly.aof" # 默认文件名
# appendfsync always
appendfsync everysec #设置对 appendonly.aof 文件进行同步的频率,
# appendfsync no #有三种选择always、everysec、no，默认是everysec表示每秒同步一次。
#always 表示每次有写操作都进行同步,everysec 表示对写操作进行累积,每秒同步一次。
# no表示等操作系统进行数据缓存同步到磁盘，都进行同步,everysec 表示对写操作进行累积,每秒同步一次
no-appendfsync-on-rewrite no #指定是否在后台aof文件rewrite期间调用fsync,默认为no,表示要调用fsync(无论后台是否有子进程在刷盘)。
#Redis在后台写RDB文件或重写aof文件期间会存在大量磁盘IO,此时,在某些linux系统中,调用fsync可能会阻塞。
auto-aof-rewrite-percentage 100 #指定Redis重写aof文件的条件，默认为100，表示与上次rewrite的aof文件大小相比，
#当前aof文件增长量超过上次aof文件大小的100%时，就会触发background rewrite。
#若配置为0，则会禁用自动rewrite
auto-aof-rewrite-min-size 64mb #指定触发rewrite的aof文件大小。若aof文件小于该值，
#即使当前文件的增量比例达到auto-aof-rewrite-percentage的配置值，也不会触发自动rewrite。
#即这两个配置项同时满足时，才会触发rewrite。
aof-load-truncated yes #是否加载不完整的aof文件来进行启动
...2.3 rewrite重写机制
AOF采用文件追加法师，文件会越来越大，为避免出现这种情况，新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程你、的内存数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
2.4 aof优缺点
优点：
- AOF文件是一个只进行追加的日志文件
- Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
- AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很容易
缺点：
- 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
- 根据所使用的fsync策略，AOF的速度可能会慢于RDB
3.总结
RDB和AOF同时启用：
1.BGSAVE和BGREWRITEAOF不会同时进行
2.Redis服务器启动时用持久化的数据文件恢复数据，会优先使用AOF
RDB和AOF恢复数据：只需要将 .rdb 或 .aof 放在数据目录下即可，重启服务会自动加载。数据目录可使用 "CONFIG GET DIR" 命令查看。
RDB和AOF备份出错不能恢复时：可使用系统提供的两个工具尝试恢复备份文件。
- redis-check-rdb
- redis-check-aof
在线修改配置：
CONFIG GET [] #得到某参数信息
CONFIG SET [] #设置某参数信息
CONFIG REWRITE #将修改的参数信息直接追加到文件末尾，不需重启服务即可生效