Redis支持两种持久化：RDB和AOF模式
一、名词解释：
RDB：持久化可以在指定的时间间隔内生成数据集的时间点快照点快照（point-in-time snapshot)。
snapshot，二进制格式：按事先定制的策略，周期性地将数据保存到磁盘：数据文件默认为dump.rdb;
客户端也可显式使用SAVA或BGSAVE命令启动快照保存机制；
SAVE：同步，在主线程中保存快照；此时会阻塞所有客户端请求；
BGSAVE：异步，不会阻塞客户端请求；
AOF：持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。记录每一次写操作至指定的文件尾部实现持久化；当redis重启时，可通过重新执行文件中的命令在内存重建数据库；
BGREWRITEAOF：AOF文件重写；不会读取正在使用的AOF文件，而通过将内存中的数据以命令的方式保存到临时文件中，完成之后替换原来的AOF文件；
AOF文件中的命令全部以redis协议的格式来保存，新命令会被追加到文件的尾部。redis还可以在后台对AOF文件进行重写（rewrite）
使得AOF文件的体积不会超出保存数据集状态所需的实际大小。
RDB和AOF的优先级：
如果同时开启RDB和AOF模式，AOF的优先级要比RDB高；
Redis还可以同时使用RDB和AOF持久化。在这种情况下，当redis重启时，它会优先使用AOF文件来还原数据集。
因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。
AOF的方式有点像ORCAL的逻辑备库！
AOF redis还会在后台对数据进行重写，比如set key1，set key2，其实set key1没用，这样做可以把set key1删掉。这样保存下来的数据集就很小了可以压缩了！
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
二、RDB&AOF优缺点
RDB的优缺点：
优点：
1、紧凑易于备份，他就一个文件。
2、RDB可以最大化redis性能、父进程无需做任何操作只需要for一个子进程即可
3、恢复比AOF快
缺点：
1、数据完整性：如果非常注重数据的完整性，那么RDB就不行，虽然他是一个point-in-tie的快照方式，但是在快照的过程中，redis重启了，那么在快照中的这些数据将会丢失；
2、数据非常庞大后，非常耗CPU和时间，那么redis将可能down掉1秒钟甚至更长。
AOF的优缺点：
优点：
1、使用AOF持久化会让redis变得非常耐久，AOF默认的每一秒追加一次也可以修改他的方式，每执行一次命令追加一次，所以你最多丢失1秒钟的数据。
2、AOF文件是一个只进行追加操作的日志文件（append only log）。
3、redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写。
缺点：
1、对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。
2、根据所使用的fsync策略，AOF的速度可能会慢于RDB。
默认Redis是开启的RDB模式的持久化的看下面配置文件：
########################### SNAPSHOTTING ######################## # # Save the DB on disk: # # save <seconds> <changes> # # 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 =================================================== 上面3个save是或的关系 # save <seconds> <changes> 333格式！ 解释： # 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 900 sec内有1个Key发生了改变就做一次快照 或 300 sec内有10个keys发生了改变做一次快照 或 60 sec内有10000 keys发生了改变做一次快照 快照原理： forker出一个进程，是当前进程的一个副本相当于子进程，不会影响你当前运行的进程！当子进程写的时候会有一个临时 的文件，当子进程写完之后会把这个临时的文件move替换老的文件，所以这个rdb的文件任何时间都是一个完整的可用的 副本！你写的时候不会影响RDB这个文件，因为forker出的子进程正在写的是一个临时文件！ 但是如果故障了，你这个保存的时间是你开始快照那一刻那个时间，你快照到快照完毕那一段时间的数据就丢失了。 如果想禁用持久化把这三行删了就行了 save 900 1 save 300 10 save 60 10000 1、快照保存在哪里呢？ # The filename where to dump the DB dbfilename dump.rdb #如果你启用了多个快照名称，可以使用端口来定义；比如：dump_6379.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模式下的DB存放在这个目录，AOF模式下也是存放在这个目录的，建议存放在指定的目录。 #比如 dir /data/redis #比如我上面指定了： # The filename where to dump the DB dbfilename dump_6379.rdb # Note that you must specify a directory here,not a file name. dir /data/redis/
2、手动在redis中保存
127.0.0.1:6379> SET key 1 OK 127.0.0.1:6379> SAVE OK 127.0.0.1:6379> quit # ll /u01/redis/ 查看文件目录下面有没有修改 -rw-r--r--. 1 root root 399 Mar 25 15:55 dump.rdb #当前时间创建 在设置一个key看下： 127.0.0.1:6379> set key 2 OK 127.0.0.1:6379> SAVE OK 127.0.0.1:6379> quit # ll /u01/redis/ -rw-r--r--. 1 root root 399 Mar 25 15:59 dump.rdb 127.0.0.1:6379> BGSAVE Background saving started SAVE和BGSAVE有什么区别：SAVE是阻塞的当你直接执行SAVE的时候他就不干活了，BGSAVE是在后台执行。 forker一个子进程来进行SAVE。 SAVE的使用场景仅限于：当redis需要迁移的时候，redis没有数据写入并且可以停的时候使用！ 测试添加一个：key然后停掉看看！不保存： 目前的key是： 127.0.0.1:6379> KEYS * 1) "key" 2) "hello" 127.0.0.1:6379> SET key3 haha OK # kill -9 `pgrep -f redis` 杀掉进程 127.0.0.1:6379> KEYS * #重启登录之后发现设置的key丢失了 1) "hello" 2) "key" #所以当redis异常挂掉之后，没有SAVE数据！
3、启动AOF后
给这个文件追加，把所有的命令都写到一个文件里面，你执行一个我写一个。恢复的话在执行一遍不就行了吗！非常简 单(但是恢复相对RDB模式会慢，他相当于重新把AOF库里的记录重新往内存中写一遍)可以RDB和AOF同时使用！优点 都占用了！但是也得根据业务来定！ 开启方法：修改配置文件 appendonly yes #改成yes appendfilename "appendonly.aof" #文件名 工作原理： forker 一个子进程写到临时文件，写完之后就给父进程发一个信号，开始写到写完的这个过程还会有子进程给父进程发信 号。先保存在内存里，但是他有个好的功能，重写，他会定时对aof进行更新，这样文件就会非常小！ 测试：（他会根据redis可识别的方式写入文件，不过大概人也能看懂） 127.0.0.1:6379> SET sichuan dazhou OK 127.0.0.1:6379> SET beijing beijing OK 127.0.0.1:6379> SET magedu peixunjigou OK 127.0.0.1:6379> SET cengdu sichuan OK 127.0.0.1:6379> KEYS * 1) "magedu" 2) "beijing" 3) "cengdu" 4) "sichuan" # cat /u01/redis/appendonly.aof *2 $6 SELECT $1 0 *3 $3 SET $7 sichuan $6 dazhou *3 $3 SET $7 beijing $7 beijing *3 $3 SET $6 magedu $11 peixunjigou *3 $3 SET $6 cengdu $7 sichuan
本文出自 “把酒问苍天” 博客，请务必保留此出处http://79076431.blog.51cto.com/8977042/1755235
原文地址：http://79076431.blog.51cto.com/8977042/1755235
