如何學會在合適的場景使用合適的技術方案，這值得思考。
由於本地環境的使用，所以搭建一個本地的Redis集群，本篇講解Redis主從復制集群的搭建，使用的平台是Windows，搭建的思路和Linux上基本一致！
（精讀閱讀本篇可能花費您15分鍾，略讀需5分鍾左右）
Redis主從復制簡單介紹
為了使得集群在一部分節點下線或者無法與集群的大多數節點進行通訊的情況下， 仍然可以正常運作， Redis 集群對節點使用了主從復制功能： 集群中的每個節點都有 1 個至 N 個復制品（replica）， 其中一個復制品為主節點（master）， 而其余的 N-1 個復制品為從節點（slave）。[ 摘自 Redis 集群中的主從復制 ]
那么上面是主從復制呢，簡單的來說就是一個主節點master可以擁有一個甚至多個從節點的slave，而一個slave又可以擁有多個slave，如此下去，形成了強大的多級服務器集群架構。
其中主節點以寫為主(可寫也可以讀)，從節點只能讀不可寫入！【讀寫分離場景】
其中主節點寫入的數據會同步（不是准實時的）到salve上，這樣如果主節點出現故障，數據丟失，則可以通過salve進行恢復。【容災恢復場景，注：因為數據不是實時同步的，可能會存在從salve恢復數據后有數據丟失問題】
綜上：下面是關於redis主從復制的一些特點：
1.一個master可以有多個slave
2.除了多個slave連到相同的master外，slave也可以連接其他slave形成圖狀結構
3.主從復制不會阻塞master。也就是說當一個或多個slave與master進行初次同步數據時，master可以繼續處理client發來的請求。相反slave在初次同步數據時則會阻塞不能處理client的請求。
4.主從復制可以用來提高系統的可伸縮性,我們可以用多個slave 專門用於client的讀請求，比如sort操作可以使用slave來處理。也可以用來做簡單的數據冗余
5.可以在master禁用數據持久化，只需要注釋掉master 配置文件中的所有save配置，然后只在slave上配置數據持久化。
6.可以用於讀寫分離和容災恢復。
Redis主從復制的常用的幾種方式
- 一主二仆 A(B、C) 一個Master兩個Slave
- 薪火相傳（去中心化）A - B - C ，B既是主節點（C的主節點），又是從節點（A的從節點）
- 反客為主（主節點down掉后，手動操作升級從節點為主節點） & 哨兵模式（主節點down掉后，自動升級從節點為主節點）
本次主要介紹一主二仆，和反客為主的操作，薪火相傳不做介紹。哨兵模式后面專門寫一篇進行介紹！
Redis主從復制的搭建（一主二仆）
1.下載Windows環境的Redis安裝包
Redis For Windows Download
或者
Redis For Windows GitHub
2.下載完成進行解壓
解壓收的目錄如下圖：
3.相關配置操作
（1）復制三份解壓后Redis
我自己本地修改了名稱，復制后文件夾名稱顯示如下：
Redis-x64-3.2.100-6379
Redis-x64-3.2.100-6380
Redis-x64-3.2.100-6381
（2）修改redis.windows.conf
6379文件夾，不做修改！
6380文件夾，修改如下：
port 6380
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379
6381文件夾，修改如下：
port 6381
slaveof 127.0.0.1 6379
我默認大家是知道redis.xx.conf的相關配置的！如果不知道，請看：
Redis學習——redis.conf 配置文件介紹
（3）加入簡單的window腳本，方便快速啟動！
在對應的redis文件夾下面新建
startRedisServer.bat
腳本的內容為：
@echo off
redis-server.exe redis.windows.conf
@pause
然后在redis文件夾同級的目錄下在新建
start6379.cmd
@echo off
cd Redis-x64-3.2.100-6379
startRedisServer.bat
然后6380和6381和上面操作一樣，操作完成后如下圖：
4.啟動測試
啟動規則：先啟動主節點，然后在啟動從節點！
（1）可以使用命令啟動
進入相應的文件夾目錄，使用啟動命令：
redis-server.exe
（2）使用腳本啟動
如上面圖片，分別執行start6379.cmd，
start6380.cmd，start6381.cmd。
先啟動Master。使用客戶端登錄，查看信息如圖：
然后啟動6380和6381，然后可以看到：如圖
在此查看6378的主從復制信息：如圖
在登錄6380和6381的客戶端，查看節點信息：如圖
測試讀寫，【主節點可讀可寫，從節點只能讀不可寫】，如下圖：
測試當主節點shutdown后，從節點的狀態【從節點可讀，從節點也不會升級為主節點】：
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381> get hello
"world"
測試當主節點重新啟動后，從節點的狀態【從節點依然可以連接主節點】：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=43,lag=0
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
127.0.0.1:6379>
小插曲【反客為主】
測試當主節點shutdown后，使用slaveof no one 是的6380成為主節點,但是也只是主節點，沒有任何從節點！：如圖
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:155
master_link_down_since_seconds:jd
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381>
127.0.0.1:6381> slave no one
(error) ERR unknown command 'slave'
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381> set test 11
OK
127.0.0.1:6381> get test
"11"
127.0.0.1:6381>
詳細可以參考 Redis主從復制 中的內容！
Redis主從復制的原理
第一種介紹
- 當設置好slave服務器后,slave會建立和master的連接，然后發送sync命令。
- Master接到命令啟動后台的存盤進程，同時收集所有接收到的用於修改數據集命令，在后台進程執行完畢之后，master將傳送整個數據文件到slave,以完成一次完全同步。
- 全量復制：而slave服務在接收到數據庫文件數據后，將其存盤並加載到內存中。（第一次全量）
- 增量復制：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步。（之后增量）
- 但是只要是重新連接master,一次完全同步（全量復制)將被自動執行。
當設置好slave服務器后，slave會建立和master的連接，然后發送sync命令。無論是第一次同步建立的連接還是連接斷開后的重新連接，master都會啟動一個后台進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令並緩存起來。后台進程完成寫文件 后，master就發送文件給slave，slave將文件保存到磁盤上，然后加載到內存恢復數據庫快照到slave上。接着master就會把緩存的命令轉發給slave。而且后續master收到的寫命令都會通過開始建立的連接發送給slave。從master到slave的同步數據的命令和從 client發送的命令使用相同的協議格式。當master和slave的連接斷開時slave可以自動重新建立連接。如果master同時收到多個 slave發來的同步連接命令，只會使用啟動一個進程來寫數據庫鏡像，然后發送給所有slave。
第二種介紹：
圖片內容來源網絡：
第三種介紹：
Redis 主從同步有兩種方式（或者所兩個階段）：全同步和部分同步。
主從剛剛連接的時候，進行全同步；全同步結束后，進行部分同步。當然，如果有需要，Slave 在任何時候都可以發起全同步。Redis 策略是，無論如何，首先會嘗試進行部分同步，如不成功，要求從機進行全同步，並啟動 BGSAVE……BGSAVE 結束后，傳輸 RDB 文件；如果成功，允許從機進行部分同步，並傳輸積壓空間中的數據。
Redis主從復制（一主兩從/一主多從）的分析
-
IO劇增
每次slave斷開以后（無論是主動斷開，還是網路故障）再連接master都要將master全部dump出來rdb，在aof，即同步的過程都要重新執行一遍；所以要記住多台slave不要一下都啟動起來，否則master可能IO劇增（間隔1-2分） -
復制延遲
由於所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。 -
可用性不高
當有主節點發生異常情況，就會導致不能寫入，導致業務出錯！[解決方法是可以使用Redis-Sentinel模式，詳情見系列文章第二篇]
注意：
Redis 集群不保證數據的強一致性（strong consistency）Redis 集群的一致性保證（guarantee）： 在特定條件下， Redis 集群可能會丟失已經被執行過的寫命令。
參考文章
附件
如果想直接使用本篇講解使用的主從配置！我已經打包好了 點擊 下載地址 進行下載！
本系列文章：
第一篇：Redis集群主從復制（一主兩從）搭建配置教程【Windows環境】
第二篇：Redis高可用集群-哨兵模式（Redis-Sentinel）搭建配置教程【Windows環境】
**如果您覺得這篇博文對你有幫助，請點個贊，謝謝！** **如果帥氣（美麗）、睿智（聰穎），和我一樣簡單善良的你看到本篇博文中存在問題，請指出，我虛心接受你讓我成長的批評，謝謝閱讀！
祝你今天開心愉快！**
歡迎訪問我的csdn博客，我們一同成長！
"不管做什么，只要堅持下去就會看到不一樣！在路上，不卑不亢!"