Redis 複製原理及分析

標籤：style   http   color   os   使用   io   strong   ar   for   

1.測試                                                                

 見master-slave測試帖

2 原理 第一次、Slave向Master同步的實現是：

        Slave向Master發出同步請求（發送sync命令），Master先dump出rdb檔案，然後將rdb檔案全量傳輸給slave，然後Master把緩衝的寫命令轉寄給Slave，初次同步完成。
第二次、以及以後的同步實現是：
        Master將變數的快照直接即時依次發送給各個Slave。
        但不管什麼原因導致Slave和Master斷開重連都會重複以上兩個步驟的過程。
        Redis的主從複製是建立在記憶體快照的持久化基礎上的，只要有Slave就一定會有記憶體快照發生。      

)

但是，我們可以很明顯的看到，RDB有他的不足，就是一旦Redis出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的，從上次RDB檔案產生到 Redis停機這段時間的資料全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價並不高。 但是對於另外一些對資料安全性要求極高的應用，無法容忍資料丟失的應用，RDB就無能為力了，所以Redis引入了另一個重要的持久化機制：AOF日誌，稍後分析。

3. Rdb快照原理  Redis支援將當前資料的快照存成一個資料檔案的持久化機制，即RDB快照。這種方法是非常好理解的，但是一個持續寫入的資料庫如何產生快照呢？

 Redis藉助了fork命令的copy on write機制（私人記憶體非共用記憶體）。在產生快照時，將當前進程fork出一個子進程，然後在子進程中迴圈所有的資料，將資料寫成為RDB檔案。

       我們可以通過Redis的save指令來配置RDB快照產生的時機，比如你可以配置當10分鐘以內有100次寫入就產生快照，也可以配置當1小時內有 1000次寫入就產生快照，也可以多個規則一起實施。這些規則的定義就在Redis的設定檔中，你也可以通過Redis的CONFIG SET命令在Redis運行時設定規則，不需要重啟Redis。

        在redis中配置：

        1、save  900 1              #當900秒內有一條Keys資料被改變時，產生RDB；
        2、save 300  10            #當300秒內有10條Keys資料被改變時，產生RDB；
        3、save 60    10000     #當60秒內有10000條Keys資料被改變時，產生RDB；

################################ 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 at all commenting all the "save" lines.save 900 1save 300 10save 60 10000

 

4. Redis的AOF日誌

     AOF日誌的全稱是append only file，從名字上我們就能看出來，它是一個追加寫入的記錄檔。與一般資料庫的binlog不同的是，AOF檔案是可識別的純文字，它的內容就是一個個 的Redis標準命令。當然，並不是發送到Redis的所有命令都要記錄到AOF日誌裡面，只有那些會導致資料發生修改的命令才會追加到AOF檔案。

 

那麼每一條修改資料的命令都產生一條日誌，那麼AOF檔案是不是會很大？
        答案是肯定的，AOF檔案會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite（使用Redis提供了bgrewriteaof命令就可以）。其功能就是重建一份AOF檔案，新的AOF檔案中一條記錄的操作只會有一次，而不像一份老檔案那樣，可能記錄了對同一個值的多次操作。其產生過程和RDB類似，也是fork一個進程，直接遍曆資料，寫入新的AOF臨時檔案（這個過程和RDB類似，但是是將資料拆分成一條一條寫命令的形式的）。在寫入新檔案的過程中，所有的寫動作記錄還是會寫到原來老的 AOF檔案中，同時還會記錄在記憶體緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時檔案中。然後調用原子性的rename命令用新的 AOF檔案取代老的AOF檔案。(這樣的操作，老的AOF可以恢複記憶體，如果產生新的AOF，老的就不存在了，可用新的AOF檔案恢複記憶體，這樣同時解決了AOF不斷增長的問題。)AOF是一個寫檔案操作，其目的是將動作記錄寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的5個流程。

 

那麼寫AOF的操作安全性又有多高呢？

實際上這是可以設定的，在Redis中對AOF調用write(2)寫入後，何時再調用fsync將其寫到磁碟上，通過appendfsync選項來控制，下面 appendfsync的三個設定項，安全強度逐漸層強。

1）appendfsync no
        當設定appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於作業系統的調試了。對大多數Linux作業系統，是每30秒進行一次fsync，將緩衝區中的資料寫到磁碟上。

2）appendfsync everysec
        當設定appendfsync為everysec的時候，Redis會預設每隔一秒進行一次fsync調用，將緩衝區中的資料寫到磁碟。但是當這一次的fsync調用時間長度超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多 長時間都會進行。這時候由於在fsync時檔案描述符會被阻塞，所以當前的寫操作就會阻塞。

        結論就是，在絕大多數情況下，Redis會每隔一秒進行一 次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的資料，一次性將日誌寫到磁碟。

3）appendfsync always
        置appendfsync為always時，每一次寫操作都會調用一次fsync，這時資料是最安全的，當然，由於每次都會執行fsync，
所以其效能也會受到影響。

Redis資料恢複：
RDB的啟動時間會更短，原因有兩個：
一、RDB檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。
二、RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。

5. Redis的Rdb檔案

在slave server執行sync命令，請求同步，如下返回rdb檔案，為二進位檔案，

redis 127.0.0.1:6380> sync"REDIS0002\xfe\x00\n\anumbers\x0f\x0f\x00\x00\x00\n\x00\x00\x00\x01\x00\x00\xc0x03\x00\xff\x00\x03old\xc0\x01\x00\bkeywatch\xc0\x03\x00\x04name\x05kerry\x00\x03aaa\xc0o\x02\aletters\x02\x01c\x01b\t\x04car1\x19\x02\x04name\x05\x00AUDIO\x05price\x03\x0030w\xff\t\x04car2\x19\x02\x04name\x05\x00AUDIO\x05price\x03\x0020w\xff\t\x04car3\x19\x02\x04name\x05\x00buick\x05price\x03\x0010w\xff\x00\x03key\x03aaa\x00\x03num\xc0\x04\x00\x02a1\xc0\x01\x00\x02a2\xc0\x02\x00\x06keynew\xc0\x04\x00\x02a3\xc0\x03\x02\bletters2\x03\x01c\x01d\x01e\x00\acompany\x03alu\x00\x0coldvalue=GET\x03old\xff"redis 127.0.0.1:6380>

具體檔案為redis目錄下，如下所示：

6. Redis的AOF檔案

預設關閉，開啟AOF設定，如下

############################## APPEND ONLY MODE ################################ By default Redis asynchronously dumps the dataset on disk. If you can live# with the idea that the latest records will be lost if something like a crash# happens this is the preferred way to run Redis. If instead you care a lot# about your data and don‘t want to that a single record can get lost you should# enable the append only mode: when this mode is enabled Redis will append# every write operation received in the file appendonly.aof. This file will# be read on startup in order to rebuild the full dataset in memory.## Note that you can have both the async dumps and the append only file if you# like (you have to comment the "save" statements above to disable the dumps).# Still if append only mode is enabled Redis will load the data from the# log file at startup ignoring the dump.rdb file.## IMPORTANT: Check the BGREWRITEAOF to check how to rewrite the append# log file in background when it gets too big.appendonly yes

windwos下無法產生，可能相容性有問題。產生的aof檔案與rdb檔案在同目錄下。

Redis 複製原理及分析