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