Redis支持两种持久化：RDB和AOF模式html
1、名词解释：python
RDB：持久化能够在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF：持久化记录服务器执行的全部写操做命令，并在服务器启动时，经过从新执行这些命令来还原数据集。redis
AOF 文件中的命令所有以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还能够在后台对 AOF 文件进行重写（rewrite）vim
使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。缓存
PDB和AOF的优先级：安全
若是同时开启RDB和AOF模式，AOF的优先级要比RDB高：
Redis 还能够同时使用 AOF 持久化和 RDB 持久化。 在这种状况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集。服务器
由于 AOF 文件保存的数据集一般比 RDB 文件所保存的数据集更完整。app
AOF 的方式有点像ORCAL的逻辑备库！
AOF redis 还会在后台对数据进行重写，好比set key1 ， set key1 ,其实第一次的set key1 没用，这样就能够把第一次set key1 删掉了。这样保存下来的数据集就很小了能够压缩了！
你甚至能够关闭持久化功能，让数据只在服务器运行时存在。post
2、RDB&AOF优缺点性能
RDB的优缺点：
优势：
一、紧凑易于备份，他就一个文件。
二、RDB能够最大化redis性能、父进程无需作任何操做只须要for一个子进程便可
三、恢复比AOF块
缺点：
一、数据完整性：若是很是注重数据的完整性，那么RDB就不行，虽然他是一个point-in-time 的快照方式，可是在快照的过程当中，redis重启了，那么在快照中的这些数据将会丢失
二、数据很是庞大后，很是耗CPU和时间，那么redis讲可能down掉1秒钟设置更长。
AOF的优缺点：
优势：
一、 使用 AOF 持久化会让 Redis 变得很是耐久，AOF默认的每一秒追加一次也能够修改他的方式没执行一次命令追加一次，因此你最多丢失1秒钟的数据
二、 AOF 文件是一个只进行追加操做的日志文件（append only log）
三、 Redis 能够在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
缺点：
一、对于相同的数据集来讲，AOF 文件的体积一般要大于 RDB 文件的体积。
二、 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB
3、RDB & AOF 持久化原理
快照的运行方式：
当 Redis 须要保存 dump.rdb 文件时， 服务器执行如下操做：
- Redis 调用 fork() ，同时拥有父进程和子进程。
- 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
- 这种工做方式使得 Redis 能够从写时复制（copy-on-write）机制中获益。
AOF 重写和 RDB 建立快照同样，都巧妙地利用了写时复制机制。
如下是 AOF 重写的执行步骤：
- Redis 执行 fork() ，如今同时拥有父进程和子进程。
- 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于全部新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即便在重写的中途发生停机，现有的 AOF 文件也仍是安全的。
- 当子进程完成重写工做时，它给父进程发送一个信号，父进程在接收到信号以后，将内存缓存中的全部数据追加到新 AOF 文件的末尾。
- 搞定！如今 Redis 原子地用新文件替换旧文件，以后全部命令都会直接追加到新 AOF 文件的末尾。
AOF重写
由于 AOF 的运做方式是不断地将命令追加到文件的末尾， 因此随着写入命令的不断增长， AOF 文件的体积也会变得愈来愈大。
举个例子， 若是你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就须要使用 100 条记录（entry）。
然而在实际上， 只使用一条 SET 命令已经足以保存计数器的当前值了， 其他 99 条记录实际上都是多余的。
为了处理这种状况， Redis 支持一种有趣的特性： 能够在不打断服务客户端的状况下， 对 AOF 文件进行重建（rebuild）。
执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。
Redis 2.2 须要本身手动执行 BGREWRITEAOF 命令； Redis 2.4 则能够自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件。
Rdis持久化设置：
默认Redis是开启的RDB模式的持久化的看下面配置文件：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
# 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
/
|
二、手动在Redis中保存
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
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收据！
|
三、启用了AOF后
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
给这个文件追加，把全部的命令都写到一个文件里面，你执行一个我写一个。
恢复的话在执行一遍不就好了吗！很是简单 （可是恢复相对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://redisdoc.com/topic/persistence.html#id7