小編以前的一篇文章《
Linux系統搭建Redis Sentinel哨兵叢集
》講述了在linux作業系統下使用redis安裝包搭建redis哨兵叢集，總的來說，這種方式比較費時費力，要修改的地方比較多，啟動也比較複雜，可能在中間某一個環節配置出了點問題，就需要花費大量的時間排查。那麼有沒有比較方便的方式來搭建Redis叢集呢？正好小編最近在學習docker和docker-compose方面的知識，使用docker-compose搭建了幾遍redis哨兵叢集，感覺方便了很多，今天就跟大家一起討論下怎麼使用docker和docker-compose搭建Redis哨兵叢集。
需要了解docker和docker-compose環境搭建的，可以透過傳送門《
Linux作業系統安裝docker和docker-compose
》先去了解一下。
說到redis哨兵叢集，就先來帶大家回顧一下redis哨兵叢集的結構，這也是加強大家後面對docker-compose。yml的深入瞭解。
Redis一主二從三哨兵叢集
主從複製
：主節點負責寫資料，從節點負責讀資料，主節點定期把資料同步到從節點保證資料的一致性。
結構上實現了讀寫分離，效能得到了大大的提升。並且，後期在遇到效能瓶頸的時候，可以適當地透過增加硬體伺服器的數量來提升軟體的效能。
但是這種單純的主從也是有缺陷的，當主伺服器宕機後，需要手動把一臺伺服器切換成主伺服器，當系統需要人工參與了，就大大增加了系統的不安全性和高風險，一旦redis服務不可用，可能會導致整個服務不能正常執行，甚至丟失大量資料，這在軟體設計上也是不允許的。
基於此，我們考慮哨兵模式。由一個或多個Sentinel例項組成的Sentinel系統可以監視任意多個主伺服器以及這些主伺服器屬下的所有從伺服器，它能夠在被監視的主伺服器下線時，自動將該主伺服器屬下的某個優先的從伺服器升級為新的主伺服器，由這個主伺服器代替已下線的主伺服器繼續處理命令請求，從而實現由系統切換代替人工啟動。
根據硬體資源的多少，我們搭建一主二從三哨兵這種redis叢集方式時，若伺服器夠多，我們可以將6個節點部署在6個伺服器上，如伺服器不夠多，我們可以在一臺伺服器上搭建一主二從，另外一臺伺服器上搭建三個哨兵，甚至在一臺伺服器上搭建6個節點，搭建環境的不同，主要影響的是docker-compose。yml的配置不同。是在一個docker-compose。yml中配置，還是在多個docker-compose。yml中配置。
（1）、編寫docker-compose.yml內容
version： ‘3’
services：
master：
image： redis
container_name： redis-master
restart： always
command： redis-server ——port 6379 ——requirepass root ——appendonly yes
ports：
- “6379：6379”
volumes：
- 。/data：/data
slave1：
image： redis
container_name： redis-slave-1
restart： always
command： redis-server ——slaveof 192。168。0。197 6379 ——port 6380 ——requirepass root ——masterauth root ——appendonly yes
ports：
- “6380：6380”
volumes：
- 。/data：/data
slave2：
image： redis
container_name： redis-slave-2
restart： always
command： redis-server ——slaveof 192。168。0。197 6379 ——port 6381 ——requirepass root ——masterauth root ——appendonly yes
ports：
- “6381：6381”
volumes：
- 。/data：/data
sentinel1：
image： redis
container_name： redis-sentinel-1
command： redis-sentinel /usr/local/etc/redis/sentinel。conf
restart： always
ports：
- “26379：26379”
volumes：
- 。/sentinel1。conf：/usr/local/etc/redis/sentinel。conf
sentinel2：
image： redis
container_name： redis-sentinel-2
command： redis-sentinel /usr/local/etc/redis/sentinel。conf
restart： always
ports：
- “26380：26379”
volumes：
- 。/sentinel2。conf：/usr/local/etc/redis/sentinel。conf
sentinel3：
image： redis
container_name： redis-sentinel-3
command： redis-sentinel /usr/local/etc/redis/sentinel。conf
restart： always
ports：
- “26381：26379”
volumes：
- 。/sentinel3。conf：/usr/local/etc/redis/sentinel。conf
引數說明：
version：版本號
services：服務
image：映象名稱
container_name：容器名稱
restart：設定開機自啟動
prots：埠對映（冒號前面的是對映後的ip，冒號後面的是對映前的ip）
volumes：資料卷對映
command：容器啟動執行命令
備註：
——requirepass：指定redis密碼
——appendonly yes：這個命令是用於開啟redis資料持久化
——slaveof ：定redis叢集主節點
——masterauth password：指定主節點密碼
（2）、在docker-compose.yml同級目錄下編寫哨兵配置sentinel.conf
配置了三個哨兵節點，因此需要編寫三個sentinel。conf，分別命名為：sentinel1。conf、sentinel2。conf、sentinel3。conf。三個檔案的內容一模一樣（也可以透過cp命令複製）
一定要注意，
sentinel.conf檔案放在docker-compose.yml同級目錄下，小編第一次就是自作主張的建了三個資料夾，放在資料夾下，導致哨兵節點一直有問題。
docker-compose.yml同級目錄下，小編第一次就是自作主張的建了三個資料夾，放在資料夾下，導致哨兵節點一直有問題。
port 26379
dir /tmp
sentinel monitor mymaster 192。168。0。197 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster root
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
命令解釋說明：
sentinel monitor 後面表示Redis監控一個叫做mymaster的執行在192。168。0。101 ：6379的redis主節點，192。168。0。101 為主節點伺服器ip，6379 為 主節點的埠，2 為最小投票數，投票達到2則表示master掛掉了【
sentinel.conf檔案內容：
，
sentinel auth-pass後面設定主節點的密碼。
sentinel parallel-syncs後面表示設定在故障轉移之後，同時可以重新配置使用新master的slave的數量。數字越低，更多的時間將會用故障轉移完成，但是如果slaves配置為服務舊資料，你可能不希望所有的slave同時重新同步master。因為主從複製對於slave是非阻塞的，當停止從master載入批次資料時有一個片刻延遲。透過設定選項為1，確信每次只有一個slave是不可到達的。
sentinel failover-timeout後面表示10秒內mymaster還沒活過來，則認為master宕機了。
針對以上的引數，有些文章說ip不是伺服器的ip，而是redis主節點的ip，可以docker inspect <主節點容器id>來檢視。也有文章說就是伺服器的ip。我們可以反思一下，當這個服務還沒起來時，是沒有這個IpAddress的，當服務起來時，這個IpAddress每次重啟都會變化。
啟動redis叢集服務
docker-compose up -d
如果啟動時發生異常，可以嘗試先執行docker-compose down將之前的容器刪除，再執行docker-compose up -d啟動。
檢視docker下redis節點的情況：
docker ps
進入主節點redis：
docker exec -it redis-master bash #進入容器
redis-cli #連線redis
auth root #輸入密碼
info replication #檢視主節點資訊資訊
檢視從節點redis資訊：
檢視哨兵節點redis資訊：
故障轉移測試（主從節點切換測試）
Redis哨兵模式可以自動轉移故障，也就是說當Redis主節點宕機的時候，它們可以透過選舉制度，在Redis從節點中選出一個節點來代替主節點，原來的從節點只能讀，切換成主節點之後，就可以實現寫的功能。我們測試先檢視主節點的資訊，然後將主節點stop，此時再檢視兩個從節點的資訊，主要觀察從節點的角色有沒有從slave切換成master。
可以看到從節點6381角色從slave切換成master，並且從節點的連線數也變成一個。