前言項目上經常用到redis進行持久化儲存，卻不知道redis持久化的原理，這裡轉載一篇部落格，權當記讀書筆記了，原文地址：http://blog.nosqlfan.com/html/3813.html寫操作的流程首先我們來看一下，資料庫在進行寫操作時到底做了哪些事，主要有下面五個過程：
- 用戶端向伺服器端發送寫操作（資料在用戶端的記憶體中）
- 資料庫服務端接收到寫請求的資料（資料在伺服器端的記憶體中）
- 伺服器端調用write（2）這個系統調用，將資料往磁碟上寫（資料在系統記憶體的緩衝區中）
- 作業系統將緩衝區中的資料轉移到磁碟控制卡上（資料在磁碟緩衝中）
- 磁碟控制卡將資料寫到磁碟的物理介質中（資料真正落在磁碟上）
故障分析寫操作大致上有上面5個流程，下面我們結合上面的5個流程看一下各種層級的故障。
- 當資料庫系統故障時，這時候系統核心還是OK的，那麼此時只要我們執行完第3步，那麼資料就是安全的，因為後續作業系統會來完成後面幾步，保證資料最終會落在磁碟上
- 當系統斷電，這時候上面5項提到的所有緩衝都會失效，並且資料庫和作業系統都會停止工作。所以只有當資料在完成第5步後，機器斷電才能保證資料不丟失，在上述四步中的資料都會丟失
通過上面5步的瞭解，可能我們會希望搞清下面的一些問題：
- 資料庫多長時間調用一個write（2）,將資料寫到核心緩衝區
- 核心多長時間會將系統緩衝區中的資料寫到磁碟控制卡
- 磁碟控制卡又在什麼時候把緩衝中的資料寫道物理介質上
對於第一個問題，通常資料庫層面會進行全面控制。而對第二個問題，作業系統有其預設的策略，但是我們也可以通過POSIX
API提供的fsync系列命令強制作業系統將資料從核心區寫到磁碟控制卡上。對於第三個問題，好像資料庫已經無法觸及，但實際上，大多數情況下磁碟緩衝
是被設定關閉的，或者是只開啟為讀緩衝，也就是寫操作不會進行緩衝，直接寫到磁碟。建議的做法是僅僅當你的磁碟有備用電池時才開啟寫緩衝。資料損毀所謂資料損毀，就是資料無法恢複，上面我們講的都是如何保證資料是確實寫到磁碟上去，但是寫到磁碟上可能並不意味著資料不會損壞。比如我們可能
一次寫請求會進行兩次不同的寫操作，當意外發生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果資料庫的資料檔案結構組織不合理，可能就會
導致資料完全不能恢複的狀況出現。這裡通常也有三種策略來組織資料，以防止資料檔案損壞到無法恢複的情況：
- 最粗糙的處理，就是不通過資料的組織形式保證資料的可恢複性。而是通過配置資料同步備份的方式，在資料檔案損壞後通過資料備份來進行恢複。
- 另一種是在上面基礎上添加一個動作記錄，每次操作時記一下操作的行為，這樣我們可以通過動作記錄來進行資料恢複。因為動作記錄是順序追加的方式寫的，所以不會出現動作記錄也無法恢複的情況
- 更保險的做法是資料庫不進行老資料的修改，只是以追加方式去完成寫操作，這樣資料本身就是一份日誌，這樣就永遠不會出現資料無法恢複的情況了
RDB快照下面我們說一下Redis的第一個持久化策略，RDB快照。Redis支援將當前資料的快照存成一個資料檔案的持久化機制。而一個持續寫入的數
據庫如何產生快照呢？Redis藉助了fork命令的copy on
write機制。在產生快照時，將當前進程fork出一個子進程，然後在子進程中迴圈所有的資料，將資料寫成為RDB檔案我們可以通過Redis的save指令來配置RDB快照產生的時機，比如你可以配置當10分鐘以內有100次寫入就產生快照，也可以配置當1小
時內有1000次寫入就產生快照，可以多個規則一起實施。這些規則的定義就在Redis的設定檔中，你可以通過Redis的CONFIG
SET命令在Redis運行時設定規則，不需要重啟RedisRedis的RDB檔案不會壞掉，因為其寫操作是在一個新進程中進行的，當產生一個新的RDB檔案時，Redis產生的子進程會先將資料寫到一
個臨時檔案中，然後通過原子性rename系統調用將臨時檔案重新命名為RDB檔案，這樣任何時間出現故障，Redis的RDB檔案都總是可用的。同時，Redis的RDB檔案也是Redis主從同步內部實現的一環。但是，我們可以很明顯的看到，RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的，從上次RDB檔案生
成到Redis停機這段時間的資料全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價並不
高。但是對於另外一些對資料安全性要求極高的應用，無法忍受資料丟人的應用，RDB就無能為力了，所以Redis引入了另一個重要的持久化機制：AOF日
志。AOF日誌aof日誌的全稱是append only
file，從名字上我們就能看出來，它是一個追加寫入的記錄檔。與一般資料庫的binlog不同的是，AOF檔案是可識別的純文字，它的內容就是一個個
的Redis標準命令。比如我們進行如下實驗，在啟動命令參數中設定開啟aof功能：
[html] view plaincopy
- sudo sed -i "s/appendonly no/appendonly yes/g" /etc/redis/redis.conf && sudo /etc/init.d/redis-server restart
然後我們執行如下命令：這時我們查看AOF記錄檔，就會得到如下內容：可以看到，寫操作都產生一條相應的命令作為日誌。其中值得注意的是最後一個del命令，它並沒有被記錄在AOF日誌中，這是因為Redis判斷
出這個命令不會對當前資料集做出修改。所以不需要記錄這個無用的寫命令。另外AOF日誌也不是完全按用戶端的請求來組建記錄檔的，比如命令
INCRBYFLOAT日誌時就被記成一條SET記錄，因為浮點數操作可能在不同的系統上會不同，所以為了避免同一份日誌在不同的系統上產生不同的資料
集，所以這裡只將操作後的結果通過SET來記錄AOF重寫你可能會想，每一條命令都產生一條日誌，那麼AOF檔案是不是會很大？答案是肯定的，AOF檔案會越來越大，所以Redis又提供了一個功能，
叫做AOF
rewrite。其功能就是重建一份AOF檔案，新的AOF檔案中一條的操作只會有一次，而不像一份老檔案那樣，可能記錄了對同一個值的多次操作。其
產生過程和RDB類似，也是fork一個進程，直接遍曆資料，寫入新的AOF臨時檔案。在寫入新檔案的過程中，所有的寫動作記錄還是會寫道原來老的AOF
檔案中，同時還會記錄在記憶體緩衝區中。當操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時檔案中。然後調用原子性rename命名用新的AOF檔案取
代老的AOF檔案從上面的流程我們能夠看到，RDB和AOF操作都是順序IO操作，效能都很高。而同時在通過RDB檔案或者AOF日誌進行資料庫恢複的時候，也是順序的讀取資料載入到記憶體中，所以也不會造成磁碟的隨機讀。資料匯入著些持久化的資料有什麼用，當然是用於重啟後的資料恢複。Redis是一個記憶體資料庫，無論是RDB還是AOF，都只是保證資料恢複的措施。所
以Redis在利用RDB和AOF進行恢複的時候，都會讀取RDB或AOF檔案，重新載入到記憶體中。相對於mysql等資料庫的啟動時間來說，會長很多，
因為Mysql本來是不需要將資料載入到記憶體中的。但是相對來說，Mysql啟動後提供服務時，其被訪問的熱資料也會慢慢載入到記憶體中，通常我們稱之為預熱，而在預熱完成前，其效能都不會太高。而Redis的好處就是一次性將資料載入到記憶體中，一次性預熱。這樣只要Redis啟動完成，那麼其提供服務的速度都是非常快的。而在利用RDB和利用AOF啟動上，其啟動時間有一些差別。RDB的啟動時間會更短，原因是兩個，一個RDB檔案中每一條資料只有一條記錄，不
會像AOF日誌那樣可能會有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼
格式是一致的，不需要再進行資料編碼工作。在CPU消耗上要遠小於AOF日誌的載入。
