标签：
Redis支持两种持久化：RDB和AOF模式
一、名词解释：
RDB：持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF：持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。
AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite）
使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
PDB和AOF的优先级：
如果同时开启RDB和AOF模式，AOF的优先级要比RDB高：
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 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-time 的快照方式，但是在快照的过程中，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模式的持久化的看下面配置文件：
vim /etc/redis/6379.conf ============================================================= ################################ 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> ###格式！ 解释： # 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发生了改变就做一次快照 或 300sec 内有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 # Note that you must specify a directory here, not a file name. dir ./ #不仅仅是RDB模式下的DB存放在这个目录AOF模式下也是存放在这个目录的，建议存放在你指定的地方！ 比如： dir /opt/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 /opt/redis/
2、手动在Redis中保存
127.0.0.1:6379> SET key 1 OK 127.0.0.1:6379> SAVE OK 下目录下面有没有修改： -rw-r--r-- 1 root root 27 Oct 14 13:35 dump_6379.rdb 当前时间创建 在设置个key看下： 127.0.0.1:6379> SET key 2 OK 127.0.0.1:6379> SAVE OK -rw-r--r-- 1 root root 27 Oct 14 13:37 dump_6379.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) "key2" 3) "key3" 127.0.0.1:6379> SET key4 4 OK 杀掉，重启之后发现设置的key丢失了。 #所以当redis异常挂掉之后，没有SAVE收据！
3、启用了AOF后
给这个文件追加，把所有的命令都写到一个文件里面，你执行一个我写一个。 恢复的话在执行一遍不就行了吗！非常简单 （但是恢复相对RDB模式回慢他相当于重新把AOF库里的记录重新往内存中写一边） 可以RDB和AOF同时使用！优点都占用了！但是也的根据业务来定！ 开启方法：修改配置文件 appendonly yes #改为yes appendfilename "appendonly.aof" #文件名 工作原理： forker 一个子进程写到临时文件，写完之后就给父进程发一个信号，开始写到写完的这个过程还会有子进程给父进程发信号。先保存在内存里 但是他有个好的功能，重写，他会定时对aof进行重新，这样文件就会非常小！ 测试：（他会根据Redis可识别的方式写入文件，不过大概人也能看懂） 16:50 [root@192.168.7.107]$ cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 SET $4 kye1
标签：
原文地址：http://www.cnblogs.com/luotianshuai/p/4969379.html
