大家可以先看這篇文章ASP.NET Redis 開發對Redis有個初步的了解
Redis的主從復制功能非常強大，一個master可以擁有多個slave，而一個slave又可以擁有多個slave，如此下去，形成了強大的多級服務器集群架構。
在master上執行寫操作，在slave上面進行讀操作，因為我們大多數場景查多一些。
實現步驟如下:
1.在Windows某個磁盤上創建兩個目錄,例如; MasterRedis(存儲的是Master服務) SlaveRedis(存儲的是Slave服務).
把Reidis文件分別拷貝一份到這兩個目錄中。
2.在Master服務中的配置文件redis.conf修改 :bind 127.0.0.1.
3.在Slave服務中的配置文件redis.conf修改：
port 6381（服務端口號要分開）
bind 127.0.0.1
slaveof 127.0.0.1 6379 （設置master的Host以及Port）
4.分別啟動Master服務與Slave服務。
啟動Master服務，開始——運行——CMD
啟動Slave服務，開始——運行——CMD
這個時候會發現我們主從服務器配置都正確了。
接下來，我們嘗試在master服務器里面寫一條數據，然后看slave服務器上面能查詢到么
再打開一個CMD窗口，
D:\Redis服務\MasterRedis>redis-cli.exe -h 127.0.0.1 -p 6379 redis 127.0.0.1:6379> set name "鄒瓊俊" OK redis 127.0.0.1:6379>
由於我們默認的redis配置：Save 900 1，表示有1個key改變，900秒以后執行快照，那么15分鍾后才會同步到slave服務器。
15分鍾后，打開slave服務器目錄下面的dump.rdb進行查看：
，表示已經同步到slave上面去了。
注意到，當我啟動master，然后啟動一個slave的時候，可以發現slave上：
[5444] 17 Apr 08:39:57 * MASTER <-> SLAVE sync started [5444] 17 Apr 08:39:57 * Non blocking connect for SYNC fired the event. [5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: receiving 10 bytes from master [5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: Loading DB in memory [5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: Finished with success
會發送一個SYNC請求，從Master上面進行相應，而且它支持自動重連，
即當master掉線的情況下，它會處於等待請求的狀態。
而Master上：
第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉發給Slave，初次同步完成。第二次以及以后的同步實現是：Master將變量的快照直接實時依次發送給各個Slave。不管什么原因導致Slave和Master斷開重連都會重復以上過程。Redis的主從復制是建立在內存快照的持久化基礎上，只要有Slave就一定會有內存快照發生。雖然Redis宣稱主從復制無阻塞，但由於Redis使用單線程服務，如果Master快照文件比較大，那么第一次全量傳輸會耗費比較長時間，且文件傳輸過程中Master可能無法提供服務，也就是說服務會中斷。
Redis數據快照
數據快照的原理是將整個Redis內存中的所有的數據遍歷一遍存儲到一個擴展名為rdb的數據文件中，通過save命令
可以調用這個過程。數據快照配置如下:
Save 900 1
Save 300 10
Save 60 10000
以上在redis.conf中的配置指出在多長時間內，有多少次更新操作，就將數據同步到數據文件中，這個可以多個條件進行配合，上面的含義是900秒后有一個key發生改變就執行save,300秒后有10個key發生改變就執行save,60秒有10000個key發生改變就執行save.
數據快照的缺點是持久化之后如果出現系統宕機則會丟失一段數據，因此增加了另外一種追加式的操作日志記錄，叫append only file,其日志文件以aof結尾，我們稱為aof文件，要開啟aof日志的記錄，需要在配置文件中進行如下配置: appendonly yes
Appendonly配置不開啟，可能在斷電時導致一段時間的數據丟失，因為redis本身同步數據文件時按save條件來同步的，所以有的數據會在一段時間內只存在於內存中。
Appendfsync no/always/everysec
no:表示等操作系統進行數據緩存同步到磁盤。性能最好，持久化沒有保障。
Always:表示每次更新操作后手動調用fsync()將數據寫到磁盤.每次收到寫命令就立即強制寫入磁盤，最慢的，但是保障完全的持久化。
Everysec:表示每秒同步一次.每秒鍾強制寫入磁盤一次，在性能和持久化方面做了很好的折中。
為了定時減小AOF文件的大小，Redis2.4以后增加了自動的bgrewriteaof的功能，Redis會選擇一個自認為負載低的情況下執行bgrewriteaof,這個重寫AOF文件的過程是很影響性能的。解決方案：Master關閉Save功能，關閉AOF日志功能，以求達到性能最佳。Slave開啟Save並開啟AOF日志功能，並開啟bgrewriteaof功能，不對外提供服務，這樣Slave的負載總體上會高於Master負載，但是Master性能達到最好.
Bgrewriterof內部實現：
1.Redis通過fork一個子進程，遍歷數據，寫入新臨時文件
2.父進程繼續處理client請求，子進程繼續寫臨時文件。
3.父進程把新寫入的AOF寫在緩沖區。
4.子進程寫完退出，父進程接收退出消息，將緩沖區AOF寫入臨時文件。
5.臨時文件重命名成appendonly.aof,原來文件被覆蓋，整個過程完成。
Redis數據恢復
當Redis服務器掛掉以后，重啟時將按以下優先級恢復數據到內存：
1.如果只配置了AOF，重啟時加載AOF文件恢復數據。
2.如果同時配置了RBD和AOF，啟動時只加載AOF文件恢復數據。
3.如果只配置了RDB，啟動時將加載dump文件恢復數據。