Redis主從複製
Redis的複製(Master/Slave)
是什麼：
行話：也就是我們所說的主從複製，主機資料更新後根據配置和策略，
自動同步到備機的master/slaver機制， Master以寫為主，Slave以讀為主
-在多臺資料伺服器中，只有 臺主伺服器，而主伺服器只負責寫入資料，不負責讓
外部程式讀取資料
-存在多臺從伺服器，從伺服器不寫入資料，只負責同步主伺服器的資料，並讓外部
程式讀取資料。
-主伺服器在寫入資料後，即刻將寫入資料的命令傳送給從伺服器，從而使得主從數
據同步。
-應用程式可以隨 讀取某 臺從 務器的資料， 這樣就分攤了讀資料的壓力。
-當從伺服器不能工作的時候，整個系統將不受影響： 當主伺服器不能工作的時候，
可以方便地從從伺服器中選舉 臺來當主伺服器
能幹嗎：
讀寫分離
容災恢復
常用3招
a.一主二僕
b.薪火相傳
c.反客為主
一主二僕
一個Master兩個Slave
日誌檢視：主機日誌，備機日誌， info replication
主從問題演示
測試：修改配置檔案實現三個埠同時開啟服務
INFO replication
SLAVEOF 127.0.0.1 6379
從機執行備份
在從主機同步之後的從機
在獲取主機新建的資料，依然能得到
從機從頭到尾複製備份
INFO replication
此時出現的問題
主機和兩個從機同時執行下面的命令
set k5 v5
此時只有主機可以寫，從機報錯
主機出問題：
從機何去何從
從機依然存在，堅守崗位，但是連線狀態改變
從機的資料依然存在
主機重新上線
從機依然可以獲取到最新的主機的資料
從機會一直待命等待主機的回來
從機出現問題：
假設80從機死了
81可以獲取最新的資料
每次與master斷開之後，都需要重新連線，除非你配置進redis.conf檔案
info replication
SLAVEOF 127.0.0.1 6379
薪火相傳
上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連線和同步請求，
那麼該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力
中途變更轉向:會清除之前的資料，重新建立拷貝最新的
slaveof 新主庫IP 新主庫埠
現在就是：
79 --> 80 --> 81
反客為主
SLAVEOF no one
使當前資料庫停止與其他資料庫的同步，轉成主資料庫
測試的前提是回到一主二僕
此時主機死了
此時80上位
81繼而連線81
此時79主機回來
依然是主機但是和80 81已經不是一個體系
複製原理
slave啟動成功連線到master後會傳送一個sync命令
Master接到命令啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令，
在後臺程序執行完畢之後，master將傳送整個資料檔案到slave,以完成一次完全同步
Master接到命令啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令，
在後臺程序執行完畢之後，master將傳送整個資料檔案到slave,以完成一次完全同步
全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。
增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
哨兵模式
反客為主的自動版，能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫
一組sentinel能同時監控多個Master
1.調整結構，6379帶著80、81
2.自定義的/myredis目錄下新建 sentinel.con f檔案，名字絕不能錯-----》 touch sentinel.conf
3.配置哨兵,填寫內容
a.sentinel monitor 被監控資料庫名字(自己起名字) 127.0.0.1 6379 1
b.面最後一個數字1，表示主機掛掉後salve投票看讓誰接替成為主機，得票數多少後成為主機
4.啟動哨兵
a. redis-sentinel /myredis/sentinel.conf
b.上述目錄依照各自的實際情況配置，可能目錄不同
此時79關機
哨兵檢測到79問題
此時讓81充當主機
此時80 81自稱一套體系
此時79重新上線
此時79成為slave成為81的從機
複製的缺點
複製延時：
由於所有的寫操作都是先在Master上操作，然後同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，
當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。