第一次、sl**e向master同步的實現是： sl**e向master發出同步請求（傳送sync命令），master先dump出rdb檔案，然後將rdb檔案全量傳輸給sl**e，然後master把快取的寫命令**給sl**e，初次同步完成。 但不管什麼原因導致sl**e和master斷開重連都會重複以上兩個步驟的過程。 redis的主從複製是建立在記憶體快照的持久化基礎上的，只要有sl**e就一定會有記憶體快照發生。 )
在sl**e啟動並連線到master之後，它將主動傳送一條sync命令。此後master將啟動後台存檔程序，同時收集所有接收到的用於修改資料集的命令，在後台程序執行完畢後，master將傳送整個資料庫檔案到sl**e，以完成一次完全同步。而sl**e伺服器在接收到資料庫檔案資料之後將其存檔並載入到記憶體中。此後，master繼續將所有已經收集到的修改命令，和新的修改命令依次傳送給sl**es，sl**e將在本次執行這些資料修改命令，從而達到最終的資料同步。
如果master和sl**e之間的鏈結出現斷連現象，sl**e可以自動重連master，但是在連線成功之後，一次完全同步將被自動執行。
redis 複製在 master 這一端是非阻塞的，也就是說在和 sl**e 同步資料的時候，master 仍然可以執行客戶端的操作命令而不受其影響。這點都不能保證，要你幹嘛？
redis 複製在 sl**e 這一端也是非阻塞的。在配置檔案裡面有 sl**e-serve-stale-data 這一項，如果它為 yes ，sl**e 在執行同步時，它可以使用老版本的資料來處理查詢請求，如果是 no ，sl**e 將返回乙個錯誤。在完成同步後，sl**e 需要刪除老資料，載入新資料，在這個階段，sl**e 會阻止連線進來。
但是，我們可以很明顯的看到，rdb有他的不足，就是一旦redis出現問題，那麼我們的rdb檔案中儲存的資料並不是全新的，從上次rdb檔案生成到 redis停機這段時間的資料全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用rdb的方式進行持久化，因為開啟rdb的代價並不高。 但是對於另外一些對資料安全性要求極高的應用，無法容忍資料丟失的應用，rdb就無能為力了，所以redis引入了另乙個重要的持久化機制：aof日誌，稍後分析。
redis借助了fork命令的copy on write機制（私有記憶體非共享記憶體）。在生成快照時，將當前程序fork出乙個子程序，然後在子程序中迴圈所有的資料，將資料寫成為rdb檔案。
我們可以通過redis的s**e指令來配置rdb快照生成的時機，比如你可以配置當10分鐘以內有100次寫入就生成快照，也可以配置當1小時內有 1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在redis的配置檔案中，你也可以通過redis的config set命令在redis執行時設定規則，不需要重啟redis。
在redis中配置：
1、s**e 900 1 #當900秒內有一條keys資料被改變時，生成rdb；
2、s**e 300 10 #當300秒內有10條keys資料被改變時，生成rdb；
3、s**e 60 10000 #當60秒內有10000條keys資料被改變時，生成rdb；
4. redis的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會每隔一秒進行一 次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的資料，一次性將日誌寫到磁碟。
redis資料恢復：
rdb的啟動時間會更短，原因有兩個：
一、rdb檔案中每一條資料只有一條記錄，不會像aof日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。
二、rdb檔案的儲存格式和redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在cpu消耗上要遠小於aof日誌的載入。
但是相對來說，mysql啟動後提供服務時，其被訪問的熱資料也會慢慢載入到記憶體中，通常我們稱之為預熱，而在預熱完成前，其效能都不會太高。而redis的好處是一次性將資料載入到記憶體中，一次性預熱。這樣只要redis啟動完成，那麼其提供服務的速度都是非常快的。
而在利用rdb和利用aof啟動上，其啟動時間有一些差別。rdb的啟動時間會更短，原因有兩個，一是rdb檔案中每一條資料只有一條記錄，不會像aof日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。另乙個原因是rdb檔案的儲存格式和redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作。在cpu消耗上要遠小於aof日誌的載入。
好了，大概內容就說到這裡。更詳細完整的版本請看redis作者的博文：redis persistence demystified。本文如有描述不周之處，就大家指正。
Redis 主從複製
主從複製的開啟，完全是在從節點發起的，不需要我們在主節點做任何事情，從節點開啟主從複製，有3種方式 主從複製主要可分為 連線建立階段 即準備階段 資料同步階段 命令傳播階段 主要作用是在主從節點之間建立連線，為資料同步做好準備 從節點資料的初始化，具體執行的方式是 從節點向主節點傳送psync命令 ...
Redis 主從複製
就是將一台 redis 伺服器的資料，複製到其他的 redis 伺服器，前者為主節點 master leader 後者稱為從節點 sl e follower 資料的複製是單向的，只能從主節點到從節點，一般 master 以寫為主，sl e 以讀為主。redis 主從複製可以根據是否是全量分為全量同步...
redis主從複製
redis的高併發有一種實現方式就是主從架構，乙個master節點，多個sl e節點，可以很好的實現sl e節點的水平擴容 主從架構再加上讀寫分離，master節點負責寫操作，sl e節點負責讀操作，使得redis可以很好的做乙個高併發的處理。有人就會疑惑了 sl e節點上的資料怎麼來的了？所以我們...