上一次呢我們講到了Redis的叢集，還有redis的主從複製，讀寫分離的一些配置，那麼接下來就接著上次還未完結的內容

上一次呢講的是在正常的情況下redis服務在各個主機上的執行情況，那麼接下來就是要介紹不正常的情況了。

假如說我們的redis的主庫掛了或者是執行redis服務的伺服器掛了，那麼其餘的redis從庫是否會趁機上位還是忠於職守在slave的角色？那麼接下來就為大家揭曉

首先啟動redis服務，包括主庫與從庫

各個伺服器上的redis服務均啟動正常，那麼接下來就是模擬redis主庫宕機了

shutdown表示關閉redis服務 
exit表示退出redis連線

那麼接下來就是檢視各個redis從庫的角色以及連線狀態了

我們可以看到，在從庫中還是可以拿到資料的，說明redis主庫掛了並不會影響redis從庫的執行。但是看到master_line_status為down的時候，就知道這個時候的主庫是掛了的，因為一開始的狀態是up

那麼如果redis主庫的服務有重新啟動了呢？redis從庫會不會再次連線上主庫？

首先啟動redis主庫，然後寫入資料，這個時候發現從庫的master_line_status的連線狀態都是up了，並且可以取到在redis主庫中寫入的資料

那麼這樣子是不是很不好啊，假如是電商網站，然後突然間redis主庫掛了，那麼這個時候就只有redis從庫服務在運行了。但是redis從庫是隻讀的是不是就無法寫入資料了，那麼客戶就無法下訂單了。那麼有沒有什麼方法，就是在redis主服務掛了之後我再從redis從庫服務中挑選出一個比較優秀的來接替主庫的位置

方案一：使用命令的方式

那麼接下來呢我們就學習一個新的命令

slaveof no one

可以看到，命令執行之後，就立刻趁機上位了，那麼另外一臺從庫是不是也要換一個新的老大啊

但是這個時候原來的redis主庫有殺回來了呢？這個時候是不是另外兩個就是有兩個redis主庫的服務了，但是原來的從庫並不會回到這個主庫上去，而是後面那兩臺自立規則。那麼這個時候是不是很不好啊，我們想要的是隻有一個redis主庫服務，那麼有沒有什麼解決方法呢？

那麼接下來就是終極的解決方案

方案二：哨兵模式

哨兵模式是反客為主的自動版，能夠jiankong 後臺主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫

首先恢復原來的一主N從的環境

接下來就是配置了

在redis安裝目錄下新建sentinel.conf檔案，名字絕不能錯 

編輯sentinel.conf檔案， sentinel monitor 被監控資料庫名字(自己起名字) 127.0.0.1 6379 1【上面最後一個數字1，表示主機掛掉後salve投票看讓誰接替成為主機，得票數多少後成為主機】 

接下來就是啟動哨兵進行監控了，命令

redis-sentinel sentinel.conf

那麼這個時候就是哨兵開始監控了

首先模擬主庫宕機，關閉主庫，並且觀察哨兵輸出的日誌並且兩個從庫角色的變化

（這裡需要等待片刻才可看到結果）大家可以看到，埠號為6381的redis從庫立馬變成了主庫，而且埠號為6380的redis從庫就跟著埠號為6381混了。

那麼問題來了，如果原來的老大回來了呢，6381會不會讓位呢？

（這裡也許等待片刻）那麼結果是原來的redis服務就變成從庫了，連線著現在的埠號為6381的主庫了。

哨兵模式的缺點：由於所有的寫操作都是先在Master上操作，然後同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。

OK，到這裡就是我們redis主從複製，讀寫分離的全部介紹了