Redis的複製(Master/Slave)
1.是什麼
1.1官網
…
1.2行話
也就是我們所說的主從複製，主機數據更新後根據配置和策略自動同步到備機的master/slave機制，Master以寫爲主，Slave以讀爲主。
2.能幹嘛
2.1讀寫分離
2.2容災恢復
3.怎麼玩
3.1配從(庫)不配主(庫)
3.2從庫配置:salveof 主庫IP 主庫端口
3.2.1 每次與master斷開之後，都需要重新連接，除非你配置進redis.conf文件
3.2.2 Info replication
3.3修改配置文件細節操作
1.拷貝多個redis.conf文件
2.開啓daemonize yes
3.Pid文件名字
4.指定端口
5.Log文件名字
6.Dump.rdb名字
拷貝多個redis.conf文件
修改每一個redis.conf文件(6379.6380.6381)
修改端口號
開啓daemonize yes
修改Pid文件名字
修改Log文件名字
修改Dump.rdb名字
注意：6379.conf,6380.conf,6381.conf 3個配置文件都需要進行修改，再次不在闡述。
wq!保存退出
3.4常用3招
1.一主二僕
2.薪火相傳
3.反客爲主
3.4.1一主二僕
啓動服務器和客戶端
查看一下 ps -ef|grep redis
先看第一個指令
info replication
看到當前3個角色都是：master
先在6379這裏設置值
然後把6379當作主人，6380.6381爲6379的僕人
slaveof 主機名 端口號
這個時候，在主機6379上存入值k4
測試一下，在6380.6381上看能不能取到k4
好，問題是k1，k2，k3能不能取到(即建立主從關係之前存入的值能不能取到)
測試一下
好的，可以取到，也就是說建立主從關係後，之前的所有數據都要保存。
我們剛纔把80.81設置成了79的僕人，可以看一下， info replication
現在來看幾個情況：
情況一：如果79.80.81都要設置一個值 k6，並且79先設置了，那麼80.81可以設置k6麼？是覆蓋還是不行報錯。
好吧，看結果就應證了主(寫)從(讀)。自己細品吧。（讀寫分離）
情況二：如果，現在主機死了（79），那麼從機（80.81）是上位變成master還是原地待命？
看到數據還是保存有，那麼看一下角色變了沒？是上位了？還是仍然是小弟。
好吧，還是一條臭鹹魚。！
情況三：現在主機又活過來了,那麼在主機設置k7，從機還能取到k7麼（也就是說主從關係還存在麼？）
好吧，主人就是主人，短暫離去，歸來仍是主人！
情況四：如果從機死了，從機再開服務，還能續借上這個主從關係麼？
假設80死了
再次啓動
可以看到從機死了就死了，再開啓，就是另外一個路了，自己是一個新的主人。
3.4.2薪火相傳
上一個Slave可以是下一個Slave的Master，Slave同樣可以接收其它slaves的連接和同步請求，那麼該slave作爲了鏈條中下一個master，可以有效減輕master的寫壓力。
中途變更轉向：會清除之前的數據，重新建立連接拷貝最新的Slaveof新主庫IP端口。
79–》80–》81
79爲80的主人，80爲81的主人
給79設置值
看下80.81是否可以拿到
可以看到，都可以拿到，那麼現在一個問題是80的角色是master還是slave？
3.4.3反客爲主
反客爲主：可以對比一下一主二從，主機掛了，從機不會上位，而反客爲主就是主機改了，從機要上位了。
把主機79搞掛掉
從機上位，我們讓80上位
給80設置值k10
那麼對於我們的81來說，有2個選擇，要不還是跟着老領導混，靜靜等待老領導回來，要麼改換門庭，跟80混。
我們就讓他跟80混吧
問題：現在79殺回來了，那麼查看一下79的信息吧。
好吧，和你79沒有關係了。
4.複製原理
1.Slave啓動成功連接到master後會發送一個sync命令
2.Master接到命令啓動後臺的存盤過程，同時收集所有接收到的用於修改數據集命令，在後臺進程執行完畢之後，master將傳送整個數據文件到slave，以完成一次完全同步
3.全量複製：而Salve服務在接收到數據庫文件數據後，將其存盤並加載到內存中
4.增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave，完成同步，但是只要是重新連接master，一次完全同步（全量複製）將自動執行。
首次全量複製，之後增量複製。
5.哨兵模式(sentinel)
公司中常用的，哨兵模式可以簡單理解成反客爲主的自動版。（有個哨兵在巡邏，只要主機掛了，哨兵就通知，在剩下的從機裏面投票選舉一個成爲新的主機）。
把79.80.81恢復成一主二從的模式
使用步驟：
1.調整目錄結構79.80.81（一主二從結構）
2.自定義的/myredis目錄下新建sentinel.conf文件，名字不能錯
3.配置哨兵，填寫內容
sentinel monitor 被監控主機名字(自己起名字) 127.0.0.1 6379 1
上面的1代表的意思：表示主機掛掉之後salve投票看讓誰接替爲主機，得票數多的爲主機。
4.啓動哨兵
5.正常主從演示
6.原有的master掛了
7.投票新選
8.重新主從繼續開工，info replication查看
問題：如果之前的master重啓回來，會不會雙master衝突？
1.調整目錄結構79.80.81（一主二從結構）
2.自定義的/myredis目錄下新建sentinel.conf文件，名字不能錯
3.配置哨兵，填寫內容
vim sentinel.conf
wq!保存退出
4.啓動哨兵
redis-sentinel /myredis/sentinel.conf
哨兵就盯着79，只要79死了，迅速在80.81中選擇一個
5.正常主從演示
//TODO…(不再演示了)
6.原有的master掛了
7.投票新選
到80已經自動變成了master
8.重新主從繼續開工
問題：如果之前的master重啓回來，會不會雙master衝突？
可以看到老領導回來之後就是80的兵了不再是老領導了。
6.複製的缺點
複製延時
由於所有的寫操作都是現在Master上操作，然後同步更新到Slave上，所以Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量增加也會使這個問題更加嚴重。