本文內(nèi)容來源于Redis 作者博文，Redis作者說，他看到的所有針對Redis的討論中，對Redis持久化 的誤解是最大的，于是他寫了一篇長文 來對Redis的持久化進行了系統(tǒng)性的論述。 什么是持久化，簡單來講就是將數(shù)據(jù)放到斷電后數(shù)據(jù)不會丟失的設備中。也就是我們通常理解的硬盤上。 寫操作的流程首先我們來看一下數(shù)據(jù)庫在進行寫操作時到底做了哪些事，主要有下面五個過程。
寫操作大致有上面5個流程，下面我們結(jié)合上面的5個流程看一下各種級別的故障。
通過上面5步的了解，可能我們會希望搞清下面一些問題：
對于第一個問題，通常數(shù)據(jù)庫層面會進行全面控制。而對第二個問題，操作系統(tǒng)有其默認的策略，但是我們也可以通過POSIX API提供的fsync系列命令強制操作系統(tǒng)將數(shù)據(jù)從內(nèi)核區(qū)寫到磁盤控制器上。對于第三個問題，好像數(shù)據(jù)庫已經(jīng)無法觸及，但實際上，大多數(shù)情況下磁盤緩存是被設置關(guān)閉的。或者是只開啟為讀緩存，也就是寫操作不會進行緩存，直接寫到磁盤。建議的做法是僅僅當你的磁盤設備有備用電池時才開啟寫緩存。 所謂數(shù)據(jù)損壞，就是數(shù)據(jù)無法恢復，上面我們講的都是如何保證數(shù)據(jù)是確實寫到磁盤上去，但是寫到磁盤上可能并不意味著數(shù)據(jù)不會損壞。比如我們可能一次寫請求會進行兩次不同的寫操作，當意外發(fā)生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果數(shù)據(jù)庫的數(shù)據(jù)文件結(jié)構(gòu)組織不合理，可能就會導致數(shù)據(jù)完全不能恢復的狀況出現(xiàn)。 這里通常也有三種策略來組織數(shù)據(jù)，以防止數(shù)據(jù)文件損壞到無法恢復的情況：
RDB快照下面我們說一下Redis的第一個持久化策略，RDB快照。Redis支持將當前數(shù)據(jù)的快照存成一個數(shù)據(jù)文件的持久化機制。而一個持續(xù)寫入的數(shù)據(jù)庫如何生成快照呢。Redis借助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然后在子進程中循環(huán)所有的數(shù)據(jù)，將數(shù)據(jù)寫成為RDB文件。 我們可以通過Redis的save指令來配置RDB快照生成的時機，比如你可以配置當10分鐘以內(nèi)有100次寫入就生成快照，也可以配置當1小時內(nèi)有1000次寫入就生成快照，也可以多個規(guī)則一起實施。這些規(guī)則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規(guī)則，不需要重啟Redis。 Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數(shù)據(jù)寫到一個臨時文件中，然后通過原子性rename系統(tǒng)調(diào)用將臨時文件重命名為RDB文件，這樣在任何時候出現(xiàn)故障，Redis的RDB文件都總是可用的。 同時，Redis的RDB文件也是Redis主從同步內(nèi)部實現(xiàn)中的一環(huán)。 但是，我們可以很明顯的看到，RDB有他的不足，就是一旦數(shù)據(jù)庫出現(xiàn)問題，那么我們的RDB文件中保存的數(shù)據(jù)并不是全新的，從上次RDB文件生成到Redis停機這段時間的數(shù)據(jù)全部丟掉了。在某些業(yè)務下，這是可以忍受的，我們也推薦這些業(yè)務使用RDB的方式進行持久化，因為開啟RDB的代價并不高。但是對于另外一些對數(shù)據(jù)安全性要求極高的應用，無法容忍數(shù)據(jù)丟失的應用，RDB就無能為力了，所以Redis引入了另一個重要的持久化機制：AOF 日志。 AOF日志aof日志的全稱是append only file，從名字上我們就能看出來，它是一個追加寫入的日志文件。與一般數(shù)據(jù)庫的binlog不同的是，AOF文件是可識別的純文本，它的內(nèi)容就是一個個的Redis標準命令。比如我們進行如下實驗，使用Redis2.6版本，在啟動命令參數(shù)中設置開啟aof功能： ./redis-server --appendonly yes然后我們執(zhí)行如下的命令： redis 127.0.0.1:6379> set key1 Hello
OK
redis 127.0.0.1:6379> append key1 ' World!'
(integer) 12
redis 127.0.0.1:6379> del key1
(integer) 1
redis 127.0.0.1:6379> del non_existing_key
(integer) 0這時我們查看AOF日志文件，就會得到如下內(nèi)容： $ cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
key1
$5
Hello
*3
$6
append
$4
key1
$7
World!
*2
$3
del
$4
key1可以看到，寫操作都生成了一條相應的命令作為日志。其中值得注意的是最后一個del命令，它并沒有被記錄在AOF日志中，這是因為Redis判斷出這個命令不會對當前數(shù)據(jù)集做出修改。所以不需要記錄這個無用的寫命令。另外AOF日志也不是完全按客戶端的請求來生成日志的，比如命令I(lǐng)NCRBYFLOAT在記AOF日志時就被記成一條SET記錄，因為浮點數(shù)操作可能在不同的系統(tǒng)上會不同，所以為了避免同一份日志在不同的系統(tǒng)上生成不同的數(shù)據(jù)集，所以這里只將操作后的結(jié)果通過SET來記錄。 AOF重寫你可以會想，每一條寫命令都生成一條日志，那么AOF文件是不是會很大？答案是肯定的，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數(shù)據(jù)，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日志還是會寫到原來老的AOF文件中，同時還會記錄在內(nèi)存緩沖區(qū)中。當重完操作完成后，會將所有緩沖區(qū)中的日志一次性寫入到臨時文件中。然后調(diào)用原子性的rename命令用新的AOF文件取代老的AOF文件。 從上面的流程我們能夠看到，RDB和AOF操作都是順序IO操作，性能都很高。而同時在通過RDB文件或者AOF日志進行數(shù)據(jù)庫恢復的時候，也是順序的讀取數(shù)據(jù)加載到內(nèi)存中。所以也不會造成磁盤的隨機讀。 AOF可靠性設置AOF是一個寫文件操作，其目的是將操作日志寫到磁盤上，所以它也同樣會遇到我們上面說的寫操作的5個流程。那么寫AOF的操作安全性又有多高呢。實際上這是可以設置的，在Redis中對AOF調(diào)用write(2)寫入后，何時再調(diào)用 appendfsync no當設置appendfsync為no的時候，Redis不會主動調(diào)用 appendfsync everysec當設置appendfsync為 這一操作在大多數(shù)數(shù)據(jù)庫系統(tǒng)中被稱為 appednfsync always當設置appendfsync為 對于pipelining有什么不同對于pipelining的操作，其具體過程是客戶端一次性發(fā)送N個命令，然后等待這N個命令的返回結(jié)果被一起返回。通過采用pipilining就意味著放棄了對每一個命令的返回值確認。由于在這種情況下，N個命令是在同一個執(zhí)行過程中執(zhí)行的。所以當設置appendfsync為everysec時，可能會有一些偏差，因為這N個命令可能執(zhí)行時間超過1秒甚至2秒。但是可以保證的是，最長時間不會超過這N個命令的執(zhí)行時間和。 與postgreSQL和MySQL的比較這一塊就不多說了，由于上面操作系統(tǒng)層面的數(shù)據(jù)安全已經(jīng)講了很多，所以其實不同的數(shù)據(jù)庫在實現(xiàn)上都大同小異。 總之最后的結(jié)論就是，在Redis開啟AOF的情況下，其單機數(shù)據(jù)安全性并不比這些成熟的SQL數(shù)據(jù)庫弱。 這些持久化的數(shù)據(jù)有什么用，當然是用于重啟后的數(shù)據(jù)恢復。 Redis是一個內(nèi)存數(shù)據(jù)庫，無論是RDB還是AOF，都只是其保證數(shù)據(jù)恢復的措施。 所以Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF文件，重新加載到內(nèi)存中。 相對于MySQL等數(shù)據(jù)庫的啟動時間來說，會長很多，因為MySQL本來是不需要將數(shù)據(jù)加載到內(nèi)存中的。 但是相對來說，MySQL啟動后提供服務時，其被訪問的熱數(shù)據(jù)也會慢慢加載到內(nèi)存中，通常我們稱之為預熱，而在預熱完成前，其性能都不會太高。而Redis的好處是一次性將數(shù)據(jù)加載到內(nèi)存中，一次性預熱。這樣只要Redis啟動完成，那么其提供服務的速度都是非?？斓摹?/p> 而在利用RDB和利用AOF啟動上，其啟動時間有一些差別。RDB的啟動時間會更短，原因有兩個，一是RDB文件中每一條數(shù)據(jù)只有一條記錄，不會像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫一次就行了。另一個原因是RDB文件的存儲格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進行數(shù)據(jù)編碼工作。在CPU消耗上要遠小于AOF日志的加載。 好了，大概內(nèi)容就說到這里。更詳細完整的版本請看Redis作者的博文：Redis persistence demystified http://oldblog./post/redis-persistence-demystified.html 。 ●本文編號78，以后想閱讀這篇文章直接輸入78即可。 ●輸入m可以獲取到文章目錄 推薦《15個技術(shù)類公眾微信》
|
|
|
