redis演練(5) redis持久化

何謂持久化，就是媳婦讓你，持久一些。

說(shuō)白了持久化：就是將內(nèi)存中的數(shù)據(jù)保存到磁盤上的過(guò)程（數(shù)據(jù)庫(kù)也算磁盤的特殊表現(xiàn)），以保證宕機(jī)或斷電后，可以繼續(xù)訪問(wèn)。java中常見(jiàn)的持久化框架，如Hibernate,ibatis,jdbc都是持久化實(shí)現(xiàn)方式的一種，當(dāng)然普通文件保存功能也算。

拿memcached來(lái)說(shuō)，memcached保存的信息，沒(méi)有進(jìn)行持久化，所以只能存活一個(gè)進(jìn)程生命期，下次重新啟動(dòng)，數(shù)據(jù)全部丟失。這算memcached的一個(gè)缺點(diǎn)吧。redis提供了持久化支持，而且提供了2種持久化方案。

《redis演練系列》，立足于案例展示，通過(guò)形象，對(duì)比，圖示的方式，達(dá)到知識(shí)梳理過(guò)程。

本章的主要梗概。

• redis兩種持久化方案對(duì)比

• redis兩種持久化方案參數(shù)說(shuō)明
  

• 演練RDB的觸發(fā)時(shí)機(jī)

• 演練AOF

• RDB VS AOF

1.redis兩種持久化方案對(duì)比

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。RDB，AOF就相當(dāng)于redis持久界的2個(gè)親兄弟，相互配合，相互提攜。當(dāng)然也會(huì)爭(zhēng)搶些資源。
RDB，簡(jiǎn)而言之，就是在不同的時(shí)間點(diǎn)，將redis存儲(chǔ)的數(shù)據(jù)生成快照并存儲(chǔ)到磁盤等介質(zhì)上；
AOF，則是換了一個(gè)角度來(lái)實(shí)現(xiàn)持久化，那就是將redis執(zhí)行過(guò)的所有寫(xiě)指令記錄下來(lái)，在下次redis重新啟動(dòng)時(shí)，只要把這些寫(xiě)指令從前到后再重復(fù)執(zhí)行一遍，就可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)了。

RDB將服務(wù)器包含的所有數(shù)據(jù)庫(kù)數(shù)據(jù)以二進(jìn)制文件的形式保存到硬盤里面。

下圖，是具體操作步驟。具體詳情參見(jiàn)【http://www.cnblogs.com/luogankun/p/3986403.html】

AOF，英文是Append Only File，即只允許追加不允許改寫(xiě)的文件。AOF方式是將執(zhí)行過(guò)的寫(xiě)指令記錄下來(lái)，在數(shù)據(jù)恢復(fù)時(shí)按照從前到后的順序再將指令都執(zhí)行一遍，就這么簡(jiǎn)單。有點(diǎn)數(shù)據(jù)庫(kù)軟件聯(lián)機(jī)日志的影子。

兩者對(duì)比

redis兩種持久化方案參數(shù)說(shuō)明

涉及到文件保存，一般要考慮以下幾個(gè)問(wèn)題，不僅僅限于redis。

• 保存時(shí)機(jī)：什么時(shí)候觸發(fā)。取決于數(shù)據(jù)一致性和效率的平衡

• 保存目標(biāo)對(duì)象：日志,二進(jìn)制...

• 保存目錄：本地目錄，還是共享目錄

• 是否壓縮：節(jié)省空間

• 是否校驗(yàn)：考慮安全

• 保存失敗處理機(jī)制：異常報(bào)告

• 開(kāi)啟線程數(shù)：決定速度，但會(huì)影響其他功能

• 保存文件限制：超過(guò)大小，不允許；和不允許上傳*.exe文件等
  

帶著這些問(wèn)題，去扣相關(guān)的RDB參數(shù)，和AOF參數(shù)，問(wèn)題就簡(jiǎn)單多了。

2.演練RDB的觸發(fā)時(shí)機(jī)

#   900 秒后如果至少有 1 個(gè) key 的值變化，則保存
#   300 秒后如果至少有 10 個(gè) key 的值變化，則保存
#   60 秒后如果至少有 10000 個(gè) key 的值變化，則保存
#   注意：你可以注釋掉所有的 save 行來(lái)停用保存功能。
#   也可以直接一個(gè)空字符串來(lái)實(shí)現(xiàn)停用：
#   save ""
save 900 1
save 300 10
save 60 10000

采用默認(rèn)的RDB配置

redis.conf

save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

2.1演練“重啟redis，鍵值丟失”

[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156

192.168.163.156:6379> flushdb
OK
192.168.163.156:6379> set blog "blog.51cto.com"
OK
#為鍵賦值
192.168.163.156:6379> get blog
"blog.51cto.com"
192.168.163.156:6379> exit
[root@hadoop2 redis]# ps -ef |grep redis
root      2546     1  0 07:42 ?        00:00:05 /usr/local/redis/bin/redis-server 192.168.163.156:6379       
root      3235  2517  0 08:54 pts/0    00:00:00 grep redis
[root@hadoop2 redis]# kill -9 2546
#重啟redis
[root@hadoop2 redis]# bin/redis-server  redis.conf 
[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
# blog鍵值丟失
192.168.163.156:6379> get blog
(nil)

這個(gè)結(jié)果，是不是非常出人意外?？磥?lái)“江湖上都傳言，redis斷電鍵值不丟失”有點(diǎn)問(wèn)題。

其實(shí)，沒(méi)問(wèn)題。是上面的演練存在不足，數(shù)據(jù)量沒(méi)有達(dá)到觸發(fā)時(shí)機(jī)要求。繼續(xù)。

2.2演練“重啟redis，鍵值不丟失”

[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
192.168.163.156:6379> set blog "blog.51cto.com"
OK
#借助自帶測(cè)試工具，發(fā)送1w請(qǐng)求，觸發(fā)RDB保存
[root@hadoop2 redis]# bin/redis-benchmark  -r 10000 -h 192.168.163.156
====== PING_INLINE ======
  100000 requests completed in 0.83 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.77% <= 1 milliseconds
...
# 確認(rèn)  鍵值還存在
[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
192.168.163.156:6379> get blog
"blog.51cto.com"
192.168.163.156:6379> exit
#關(guān)閉 redis服務(wù)
[root@hadoop2 redis]# ps -ef |grep redis
root      3241     1  3 08:54 ?        00:00:19 bin/redis-server 192.168.163.156:6379
root      3351  2517  0 09:05 pts/0    00:00:00 grep redis
[root@hadoop2 redis]# kill -9 3241
#重啟redis服務(wù)
[root@hadoop2 redis]# bin/redis-server  redis.conf 
#確認(rèn)重啟后,blog鍵值依然存在
[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
192.168.163.156:6379> get blog
"blog.51cto.com"

看來(lái)“江湖上都傳言，redis斷電鍵值不丟失”,是有前提條件的。

3.演練AOF

 修改redis.conf 開(kāi)啟AOF 關(guān)閉RDB

save 900 1
save 300 10
save 60 10000
save ""
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 16mb
aof-load-truncated yes

3.1演練重啟redis，鍵值是否丟失

192.168.163.156:6379> set blog "blog.51cto.com"
OK
192.168.163.156:6379> exit
[root@hadoop2 redis]# pkill redis
#重啟
[root@hadoop2 redis]# bin/redis-server  redis.conf 
[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
#鍵值未丟失
192.168.163.156:6379> get blog
"blog.51cto.com"

結(jié)論：托AOF的福，鍵值沒(méi)有丟失，和RDB不同。原因是兩者的觸發(fā)時(shí)機(jī)不同。

這時(shí)候，確認(rèn)下生產(chǎn)AOF文件

#僅僅存了一條記錄
[root@hadoop2 redis]# ll
-rw-r--r--. 1 root root    67 9月   3 10:31 appendonly.aof
#查看日志內(nèi)容(為文本文件)
[root@hadoop2 redis]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
blog
$14
blog.51cto.com

3.2演練重啟AOF重寫(xiě)效果

通過(guò)查看日志內(nèi)容，可以確認(rèn)存放的是操作命令日志。這勢(shì)必導(dǎo)致文件大小增長(zhǎng)過(guò)快，這和RDB文件不同。RDB存儲(chǔ)的是二進(jìn)制文件，而且是某時(shí)刻的快照，存儲(chǔ)的本身就是面向內(nèi)存結(jié)果。稍后會(huì)提供例子演示下RDB的內(nèi)容。

準(zhǔn)備測(cè)試數(shù)據(jù)

[root@hadoop2 redis]# bin/redis-cli  -h  192.168.163.156
#順序操作鍵值多次
192.168.163.156:6379> set year 2001
OK
192.168.163.156:6379> incr year
(integer) 2002
192.168.163.156:6379> incr year
(integer) 2003
192.168.163.156:6379> incr year
(integer) 2004
192.168.163.156:6379> incr year
(integer) 2005
192.168.163.156:6379> incr year
(integer) 2006
192.168.163.156:6379> incr year
(integer) 2007
192.168.163.156:6379> incr year
(integer) 2008
192.168.163.156:6379> incr year
(integer) 2009
192.168.163.156:6379> incr year
(integer) 2010
192.168.163.156:6379> get year
"2010"
# get沒(méi)有輸出到AOF日志
[root@hadoop2 redis]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
blog
$14
blog.51cto.com
*2
$6
SELECT
$1
0
*3
$3
set
$4
year
$4
2001
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year
*2
$4
incr
$4
year

#接下來(lái)，借助benchmark工具，批量插入數(shù)據(jù)，觸發(fā)AOF文件重寫(xiě)
[root@hadoop2 redis]# bin/redis-benchmark  -r 20000 -h 192.168.163.156

#appendonly.aof文件變化過(guò)程(11M->27M -->32M->33M->42M->8.5M.
...
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 11M 9月   3 11:03 appendonly.aof
-rw-r--r--. 1 root root 27M 9月   3 11:03 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 32M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 33M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 36M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 42M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 44M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 8.5M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 11M 9月   3 11:04 appendonly.aof
[root@hadoop2 redis]# ll appendonly.aof  -h
-rw-r--r--. 1 root root 15M 9月   3 11:04 appendonly.aof

從42M 突然變成了8.5M，明顯發(fā)生了AOF重寫(xiě)操作。

以year為目標(biāo)，確認(rèn)下AOF重寫(xiě)發(fā)生了什么。

重寫(xiě)前后，發(fā)現(xiàn)將多次操作的結(jié)果，轉(zhuǎn)換為一個(gè)等價(jià)的命令，大大降低了存儲(chǔ)空間。

1.我們也可以使用bgrewriteaof來(lái)手動(dòng)觸發(fā)AOF的自動(dòng)重寫(xiě)。

2 .調(diào)用 BGSAVE 能手動(dòng)觸發(fā)快照保存,保存快照。

但線上環(huán)境要注意，阻塞情況。

4.AOF VS RDB.

兩種持久化方式，不是水火不容，而是相互扶持，相融以沫。

官方文檔，建議兩者同時(shí)開(kāi)啟

同時(shí)開(kāi)啟兩種持久化(redis.conf)

save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 16mb
aof-load-truncated yes

4.1比較2種方式的文件存儲(chǔ)

1.刪除rdb,aof文件
2.重啟redis-server
#3.批量發(fā)送1w條請(qǐng)求
[root@hadoop2 redis]# bin/redis-benchmark  -r 10000 -h 192.168.163.156
#4. 比較2個(gè)文件大小
[root@hadoop2 redis]# ll -h
總用量 29M
-rw-r--r--. 1 root root  192 9月   3 10:58 1
-rw-r--r--. 1 root root  28M 9月   3 11:26 appendonly.aof
-rw-r--r--. 1 root root 457K 9月   3 11:26 dump.rdb

4.2 演練aof文件損壞

[root@hadoop2 redis]# bin/redis-server  redis.conf 
[root@hadoop2 redis]# bin/redis-cli  -h 192.168.163.156
192.168.163.156:6379> set blog "blog.51cto.com"
OK
192.168.163.156:6379> set subject "redis"
OK

192.168.163.156:6379> set year 2016
OK
192.168.163.156:6379> keys *
1) "year"
2) "subject"
3) "blog"

手動(dòng)修改下appendonly.aof 文件

使用redis-check-aof 驗(yàn)證下，果然不出所料“文件有問(wèn)題”

[root@hadoop2 redis]# bin/redis-check-aof 
Usage: bin/redis-check-aof [--fix] <file.aof>
[root@hadoop2 redis]# bin/redis-check-aof  appendonly.aof 
0x               0: Expected \r\n, got: 0a00
AOF analyzed: size=112, ok_up_to=0, diff=112
AOF is not valid

...查看啟動(dòng)日志(WARRING 暫時(shí)先放著)

4690:M 03 Sep 11:42:12.213 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
4690:M 03 Sep 11:42:12.213 # Server started, Redis version 3.2.3
4690:M 03 Sep 11:42:12.213 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
4690:M 03 Sep 11:42:12.214 # Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

客戶端連接失敗

[root@hadoop2 redis]# bin/redis-cli  -h 192.168.163.156
Could not connect to Redis at 192.168.163.156:6379: Connection refused

修復(fù)aof文件

[root@hadoop2 redis]# bin/redis-check-aof
Usage: bin/redis-check-aof [--fix] <file.aof>
[root@hadoop2 redis]# bin/redis-check-aof --fix appendonly.aof
0x               0: Expected \r\n, got: 0a00
AOF analyzed: size=112, ok_up_to=0, diff=112
This will shrink the AOF from 112 bytes, with 112 bytes, to 0 bytes
Continue? [y/N]: y

Successfully truncated AOF

#修復(fù)的結(jié)果是清空了AOF文件。

重啟成功了，但遺憾的是數(shù)據(jù)全丟失了。

bin/redis-server  redis.conf

[root@hadoop2 redis]# cat appendonly.aof

bin/redis-cli  -h  192.168.163.156
192.168.163.156:6379> keys *
(empty list or set)

當(dāng)然，演示AOF文件出問(wèn)題，這是個(gè)比較嚴(yán)重的問(wèn)題?？梢?jiàn)備份的重要性。

AOF方式的另一個(gè)好處，我們通過(guò)一個(gè)“場(chǎng)景再現(xiàn)”來(lái)說(shuō)明。某同學(xué)在操作redis時(shí)，不小心執(zhí)行了FLUSHALL，導(dǎo)致redis內(nèi)存中的數(shù)據(jù)全部被清空了，這是很悲劇的事情。不過(guò)這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件還沒(méi)有被重寫(xiě)（rewrite），我們就可以用最快的速度暫停redis并編輯AOF文件，將最后一行的FLUSHALL命令刪除，然后重啟redis，就可以恢復(fù)redis的所有數(shù)據(jù)到FLUSHALL之前的狀態(tài)了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF文件已經(jīng)被重寫(xiě)了，那就無(wú)法通過(guò)這種方法來(lái)恢復(fù)數(shù)據(jù)了。

前人，曾靜曰過(guò)的。難道有問(wèn)題。于是我重新實(shí)驗(yàn)了下。

這次我加快了速度，立刻關(guān)閉redis服務(wù)，以及使用vi命令直接修改aof文件。結(jié)果卻是可以將數(shù)據(jù)恢復(fù)。

這個(gè)演示不補(bǔ)貼了。

正是有了持久化，才使redis向“存儲(chǔ)”靠近了一大步，數(shù)據(jù)可靠性提供了保證。

友情提示，演練文章，最好配合官方理論說(shuō)明性文檔一同觀看，效果顯著。