Redis主從復制是什么？
行話：也就是我們所說的主從復制，主機數據更新后根據配置和策略，
自動同步到備機的master/slaver機制，Master以寫為主，Slave以讀為主
Redis主從復制能干些什么？
（1）讀寫分離
（2）容災恢復
Redis配置主從復制（1主2從）
知識注意：
（1）配從(庫)不配主(庫)
（2）從庫配置：slaveof 主庫IP 主庫端口
（3）info replication查看當前redis節點信息（是主還是從等等）
redis配置1主2從
開始配置：
這里做演示是裝在一台機器上，方便學習（生產環境是裝在不同機器上的）
我們這里並不安裝三個redis，而是已copy三個配置文件來區分。
分別是：redis6379.conf，redis6380.conf，redis6381.conf
修改配置文件內容：（這里的修改都是為了區分不同機器，6379就是端口號）
daemonize yes：開啟后台啟動
pid /var/run/redis6379.pidpid文件以端口號來區分
P ort 6379指定端口
logfile "redis6379.log"指定log文件名字
dbfilename dump6379.rdb這里使用的是rdb持久化方式，那么就修改rdb快照文件名
（每個配置文件都需要修改）
修改好配置文件后，分別啟動三個redis進程：
../bin/redis-server redis6379.conf
../bin/redis-server redis6380.conf
../bin/redis-server redis6381.conf
查看是否啟動成功：
可以看到redis三個進程分別在6380,6381,6379三個端口號啟動了。
分別連接這三個redis進程，查看當前redis狀態：
6379端口：
6380端口：
6381端口：
現在可以看到，三個redis進程狀態都是master，都沒有slave。
開始主從復制配置：
一個master，兩個slave。
定義：6379當master，6380和6381都為slave
可以看到我們只是注意的地方：配從(庫)不配主(庫)
好的，分別在6380和6381上的redis去關聯6379的redis：
slaveof 127.0.0.1 6379
（注意：我們這里是以命令方式去關聯主的，當前redis關閉即失效。如果想要重新啟動還能關聯主，那么需要再配置文件中配置。）
然后我們再查看6380和6381端口redis的狀態：
可以看到兩台主機都已經改成slave了，而且還標識出master的信息。
如果已經出現以上圖片顯示，那么代表1主2從配置成功了。
測試redis的1主2從
（1）slave1、slave2是從頭開始復制還是從切入點開始復制?當前主機器上已經有了k1 k2 k3了，從機器才關聯過來，那么在從機器上能拿到k1 k2 k3嗎？
測試：
主服務器先寫key
從服務再去關聯主服務器，去拿key
答案是可以的！！！分析一下，應該是從機器關聯主機器時，會將主機器所有key都copy一份給從機器
（2）從機是否可以寫？set可否？主服務器是否可以讀呢？get可否
測試：
在從機上寫：redis會提示你只是一個從機，是只能讀不能寫。
在主機上讀：可以讀，主機可讀可寫
（3）主機shutdown后情況如何？從機是上位還是原地待命
測試：
主機shutdown：
查看從機狀態：
可以看到，從機狀態還是沒有改變，從機是在原地待命
（4）主機又回來了后，主機新增記錄，從機還能否順利復制？
測試：
從新啟動主機，寫入一個k5
在從機上獲取k5：
從機上獲取k5成功。
得出結論：
主機回來后並且新增記錄，從機能順利復制主機上的數據。
（5）其中一台從機down后情況如何？依照原有它能跟上大部隊嗎？
測試：
關閉從機，重新啟動從機。
主機寫入k6，從機上獲取k6，會發現是不行的。
為什么呢？安裝的時候已經說了：
（注意：我們這里是以命令方式去關聯主的，當前redis關閉即失效。如果想要重新啟動還能關聯主，那么需要再配置文件中配置。）
如果不相信可以去看下當前從機的狀態，它已經變成master了。
這里就不貼截圖了。
薪火相傳
什么是薪火相傳？
上一個slave可以是下一個slave的master，slave同樣可以接收其他
slaves的連接和同步請求，那么該slave作為了鏈條中下一個的master,
可以有效減輕master的寫壓力。
注意：
中途變更轉向:會清除之前的數據，重新建立拷貝最新的
設置薪火相傳
slaveof 新主庫IP 新主庫端口
我這里還是拿之前配好的6379,6380,6381來做案例。
主機：6379
從機：6380,6381
將6381指向6380,。6380還是指向6379（不變）。
6381端口redis信息：
6380端口redis信息：
可以看到6380端口的redis還是slave，但是它底下有一個slave，正是6381，好的現在我們已經配置成功了。
測試一下：在6379下修改個值，6380上一定是可以取到的，看看6381上能不能取到
ok，6381上也是可以拿到值的，那么薪火相傳成功！！！！
反客為主
什么是反客為主？
當主機中宕機了，那么我們可以手動的停止從機與主機的同步，將從機轉成主機。再將其他的從機與當前這台主機同步數據，另成一個體系。
命令介紹：
slaveof no one使當前數據庫停止與其他數據庫的同步，轉成主數據庫。
反客為主案例：
假如現在主機掛掉了：這里是人為手動關閉，模擬掛掉
查看從機狀態：
這里可以發現master的狀態是down，那么現在將80端口redis設置為主機，81端口redis做80端口的從機：
slaveof no one使當前數據庫停止與其他數據庫的同步，轉成主數據庫。
Info replication查看當前redis的一個信息，可以發現當前已經是master了
再將81關聯到80上，再查看當前81上的信息，就可以看到關聯的master是80的redis了。
slaveof 127.0.0.1 6380
測試主從復制是否成功：
測試成功！！在80上寫數據，在81上可以讀取到。
Redis主從復制原理
全量復制：
slave啟動成功連接到master后會發送一個sync命令
master接到命令啟動后台的存盤進程，同時收集所有接收到的用於修改數據集命令，
在后台進程執行完畢之后，master將傳送整個數據文件到slave,以完成一次完全同步
而slave服務在接收到數據庫文件數據后，將其存盤並加載到內存中。
增量復制：
master繼續將新的所有收集到的修改命令依次傳給slave，完成同步。
注意：
（但是只要是重新連接master，回自動執行一次完全同步（全量復制)）
哨兵模式(sentinel)
什么是哨兵模式？
反客為主的自動版，能夠后台監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫。
實現哨兵模式
我們還是使用6379,6380,6381機器來演示。
（先調回1主2從情況，這里就不演示了。）
主機：6379
從機：6380，6381
（1）在/usr/local/redis/conf下創建一個名為sentinel.conf的文件，並寫入內容
sentinel monitor 被監控數據庫名字(自己起一個名字) 127.0.0.1 6379 1
上面最后一個數字1，表示主機掛掉后salve投票看讓誰接替成為主機，得票數多的redis成為主機
注意：這里要監控的是主機
（2）啟動哨兵
這是我的目錄：
bin下面就是redis的一些啟動腳本。
config下是我copy出來的redis配置文件和剛剛創建的sentinel.conf
到config目錄下執行命令啟動哨兵：
../bin/redis-sentinel sentinel.conf
（注意：這里的命令根據不同的redis安裝目錄也是會不相同的。）
好的，如果看到以上打印出得圖就是啟動成功。可以看到已經在監控6379了，而且還找到了6379的從機器6380和6381。
哨兵測試
（1）原有的master掛了，會怎么樣？
好的，我們測試一下，我們手動讓6379掛掉，看下哨兵會怎么處理。
模擬6379宕機：（手動讓6379宕掉）
稍等一會，看到哨兵日志：
這里已經檢測到6379主機宕機，那么就會投票選出一個主機，這里可以看到的是選出的主機是6380。
我們去看下6380和6381的信息
6380：
6381：
以上截圖已經可以看到，6380已經成了主機，而且6381已經改變了關聯的主機，改成選舉出來的6380了。
總結出：如果主機掛掉了，那么會在從機上投票選舉出主機，並且修改剩余的從機關聯到新的主機中。
（2）如果之前的master重啟回來，會不會雙master沖突？
測試開始：
重新啟動6379端口的redis，查看它的信息，看一看是什么情況：
可以看到6379變成了slave，主機是6380。
而且啟動6379時，哨兵打印出了一條日志：
意思：將從機6379關聯到6380上。
總結：之前的master重新啟動后，並不會沖突，會以從機的身份來關聯主機。
注意：一組sentinel能同時監控多個Master
復制的缺點
復制的延遲：
由於所有的寫操作都是先在master上操作，然后同步更新到slave上，所以從master同步到slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，slave機器數量的增加也會使這個問題更加嚴重。
好的。到了這里主從復制和哨兵模式完成！！！