公司專案涉及到redis，最近不太忙於是準備仔細學習下，起初是直接在Windows下搭建，現在試試Docker下搭建redis然後試下哨兵配置，廢話不多說，直接搭建步驟：

1.Docker安裝redis

指令1）docker search redis

查詢redis映象，結果顯示不同版本

2）docker pull redis

docker 直接拉取redis映象 ，預設最新版本

2.搭建redis主從複製（讀寫分離）配置

2.1.建立redis容器例項

指令：

docker run --name redis-6379 -p 6379:6379 -d redis

docker run --name redis-6380 -p 6380:6379 -d redis

docker run --name redis-6381 -p 6381:6379 -d redis

如果以前建立過相同redis容器例項

docker ps -a 檢視顯示所有的容器，包括未執行的。

docker restart name

進入容器內部 : docker exec -it redis-6379 /bin/bash

啟動 redis 客戶端 連線本地的 redis 服務 :redis-cli

                             連線遠端的 redis 服務 :redis-cli -h host -p port -a password

2.2 按照1主2從的結構搭建，即1個Master，2個Slaver節點

2.2.1 檢視容器內網的ip地址等資訊

docker inspect containerid 

redis-6379：172.17.0.2:6379

redis-6380：172.17.0.3:6379

redis-6381：172.17.0.4:6379

2.2.2 使用命令修改配置

指令：SLAVEOF host port

SLAVEOF 172.17.0.2 6379

通過指令如果不改動redis.conf配置檔案，容器宕機再次啟動時則的需要重新手動配置

2.2.3 修改redis.conf配置檔案

redis預設無配置檔案，於是需要手動新增

直接修改slaveof、logfile、dir配置

dir:工作目錄（存放日誌檔案、持久化檔案）

logfile:日誌檔名稱

3.搭建redis哨兵（主從切換）配置   

3.1 首先了解下為什麼需要哨兵配置 

       redis主從模式解決了資料備份和單例可能存在的效能問題，但是其也引入了新的問題。由於主從模式配置了三個redis例項，並且每個例項都使用不同的ip（如果在不同的機器上）和埠號，根據前面所述，主從模式下可以將讀寫操作分配給不同的例項進行從而達到提高系統吞吐量的目的，但也正是因為這種方式造成了使用上的不便，因為每個客戶端連線redis例項的時候都是指定了ip和埠號的，如果所連線的redis例項因為故障下線了，而主從模式也沒有提供一定的手段通知客戶端另外可連線的客戶端地址，因而需要手動更改客戶端配置重新連線。另外，主從模式下，如果主節點由於故障下線了，那麼從節點因為沒有主節點而同步中斷，因而需要人工進行故障轉移工作。

      為了解決這兩個問題，在2.8版本之後redis正式提供了sentinel（哨兵）架構。關於sentinel，這裡需要說明幾個概念：

      每個sentinel節點其實就是一個redis例項，與主從節點不同的是sentinel節點作用是用於監控redis資料節點的，而sentinel節點集合則表示監控一組主從redis例項多個sentinel監控節點的集合，比如有主節點master和從節點slave-1、slave-2，為了監控這三個主從節點，這裡配置N個sentinel節點sentinel-1，sentinel-2，...，sentinel-N。如下圖是sentinel監控主從節點的示例圖：

      從圖中可以看出，對於一組主從節點，sentinel只是在其外部額外新增的一組用於監控作用的redis例項。在主從節點和sentinel節點集合配置好之後，sentinel節點之間會相互發送訊息，以檢測其餘sentinel節點是否正常工作，並且sentinel節點也會向主從節點發送訊息，以檢測監控的主從節點是否正常工作。。前面講到，sentinel架構的主要作用是解決主從模式下主節點的故障轉移工作的。這裡如果主節點因為故障下線，那麼某個sentinel節點發送檢測訊息給主節點時，如果在指定時間內收不到回覆，那麼該sentinel就會主觀的判斷該主節點已經下線，那麼其會發送訊息給其餘的sentinel節點，詢問其是否“認為”該主節點已下線，其餘的sentinel收到訊息後也會發送檢測訊息給主節點，如果其認為該主節點已經下線，那麼其會回覆向其詢問的sentinel節點，告知其也認為主節點已經下線，當該sentinel節點最先收到超過指定數目（配置檔案中配置的數目和當前sentinel節點集合數的一半，這裡兩個數目的較大值）的sentinel節點回復說當前主節點已下線，那麼其就會對主節點進行故障轉移工作，故障轉移的基本思路是在從節點中選取某個從節點向其傳送slaveof no one（假設選取的從節點為127.0.0.1:6380），使其稱為獨立的節點（也就是新的主節點），然後sentinel向其餘的從節點發送slaveof 127.0.0.1 6380命令使它們重新成為新的主節點的從節點。重新分配之後sentinel節點集合還會繼續監控已經下線的主節點（假設為127.0.0.1:6379），如果其重新上線，那麼sentinel會向其傳送slaveof命令，使其成為新的主機點的從節點，如此故障轉移工作完成。

3.2 Sentinel哨兵特點

監控（Monitoring）： Sentinel 會不斷地檢查你的主伺服器和從伺服器是否運作正常。

提醒（Notification）： 當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程式傳送通知。

自動故障遷移（Automatic failover）： 當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主伺服器的其中一個從伺服器升級為新的主伺服器， 並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； 當客戶端試圖連線失效的主伺服器時， 叢集也會向客戶端返回新主伺服器的地址， 使得叢集可以使用新主伺服器代替失效伺服器。

3.3 哨兵配置

redis預設無sentinel.conf，所以需要自己建立

進入根目錄建立sentinel.conf檔案

cd / && touch sentinel.conf

修改檔案內容為：

sentinel monitor mymaster 172.17.0.2 6379 1

使用指令vim編輯sentinel.conf時如果有如下錯誤

如果出現：bash: vim: command not found
解決：1、apt-get update          2、apt-get install vim

原因為編輯該檔案時異常退出，而vim在編輯檔案時會建立一個交換檔案swap file以保證檔案的安全性，所以在每次開啟這個檔案都會出現警告，該檔案是隱藏的，可通過ls -la命令檢視，使用rm命令進行刪除

最後，啟動Redis哨兵：

使用 redis-sentinel /sentinel.conf 啟動Redis哨兵監控
使用 ps –ef |grep redis 命令，可以看到redis-server和redis-sentinel正在執行

至此配置3個Sentinel節點，Sentinel哨兵配置完畢。

4.驗證

關閉主機，將剛才停止的主機啟動起來，發現啟動後其自動成為從機

參考：