基於sentinel構建高可用redis集羣的注意事項

部署redis高可用集羣時，一般會用到redis官方的sentinel。sentinel監控master情況，master宕機時進行集羣master的故障轉移。部署時方法網上不少，這裏列出了一些須要注意的事項。

設置相同的集羣密碼

爲了安全，有時候會對redis和sentinel設置密碼，因爲集羣可能會切換，因此redis集羣的密碼最好相同，對於將slave-priority設置爲0的節點，因爲不會成爲master，因此密碼能夠單獨設置，不與其餘機器相同，只要masterauth設置爲master的密碼便可。

sentinel在redis5之後的版本支持設置密碼，因爲sentinel之間須要相互通訊，因此整個sentinel集羣內密碼必須相同。固然不須要與redis節點的密碼相同

redis綁定本地IP

redis配置文件的bind指令能夠綁定多個IP, 默認綁定了127.0.0.1。若是sentinel不在本機，須要redis綁定外網IP，這時bind綁定的第一個IP必須能夠對外訪問。

redis的主從複製須要slave和master通訊，而redis對外創建TCP鏈接時，會使用bind綁定的第一個IP做爲本地IP，如配置了bind 127.0.0.1 1.1.1.1，slave訪問master時，會綁定127.0.0.1，master若是不是本機，會鏈接失敗。

配置文件的dir放在其餘路徑相關指令的前面

dir指令改變後面指令的相對路徑，若是配置中有其餘依賴相對文件路徑的指令，如pidfile、logfile，要把這些指令放在dir指令後面。

禁用CONFIG指令致使沒法切換master

redis的CONFIG指令會修改本地文件，致使安全風險，而在配置文件中加入rename-command CONFIG ""，能夠禁用CONFIG指令。

sentinel檢測到master宕機進行故障切換時，會向slave發送一個事務指令（MULTI), 包含有SLAVEOF和CONFIG兩個指令，SLAVEOF指令指示slave更換master，CONFIG指令將slaveof更新到配置文件裏。若是禁用了CONFIG指令會致使事務失敗，相應的slave沒法切換master。

sentinel機器無外網IP需經過announce-ip指定

redis和sentinel都支持announce-ip和announce-port聲明ip和端口，若是對外提供服務的IP與對外訪問的出口不一致時須要指定這個配置，尤爲如今不少雲主機都是隻有內網IP，經過slb對外訪問的。

sentinel之間的相互發現是靠master來實現的，sentienl向master的__sentinel__:hello"的channel廣播本身的IP地址，其餘sentinel根據這個消息發現其餘的sentinel。若是sentienl的機器是內網的，而sentinel之間須要外網訪問，就須要在配置文件裏，將announce-ip配置爲外網能夠訪問的IP。而redis之間，地址經過TCP鏈接的對端地址獲取，不存在這個問題。

向運行中sentinel增長帶有密碼的redis集羣

sentinel經過讀取配置文件獲取master信息，同時運行中的sentinel也能夠經過指令配置。

在經過sentinel monitor能夠增長監控的集羣時，若是集羣帶有密碼，經過sentinel set 集羣名 auth-pass password來設置。設置後須要經過sentinel reset 集羣名，讓sentinel從新與集羣master創建TCP鏈接才能真正生效。

不要對已加入集羣的redis執行手動執行slaveof

sentinel會監控集羣中節點的狀態，若是對redis集羣內的機器手動執行slaveof執行，sentinel發現後會從新發送slaveof指令，保證集羣的正常運行。

從集羣內移除節點

若是節點是slave，先將節點宕機，而後向全部監控這個集羣的sentinel，發送sentinel reset 集羣名重置集羣節點信息，將節點從集羣完全移除，保證全部的sentinel都執行了這個指令，不然sentinel會從新發送slaveof指令將節點加入集羣。

若是節點是master，須要切換master，後照slave的狀況進行。

移除sentinel節點，與移除slave方法相同。

redis集羣多層級

redis主從複製支持多層級，若是使用了sentinel，集羣的管理可能出現混亂。

如node1有兩個從節點node2和node3，node2有一個從節點node4。若是node1宕機，sentinel將集羣的master切換到了node2,那麼node3和node4就變成了同一個層級的，這時sentinel該若是處理？不過並無實際進行驗證，不肯定的狀況下最好避免這種情形。

sentinel故障切換時如何選擇slave

sentinel發現master宕機時，改成每一秒向全部的slave發送INFO指令，以及時獲取slave狀態。以後須要選擇一個slave提高爲集羣master。

在選擇slave時，將鏈接正常，且slave-priority不爲0的slave組成一個數組，按照節點的slave-priority從小到大排序，對於slave-priority值相同的節點，依照節點的slave_repl_offset值從大到小排序（slave_repl_offset爲主從複製的偏移，值越大說明節點的數據越接近master）。排序完成後，選擇數組中最前面的節點，提高爲集羣master。

redis集羣數據不知足強一致性

redis主從複製並無提供強一致性，因此從slave讀到的數據與master可能有延遲。且master故障切換時數據可能會丟失。

senetinel並不關注redis主從複製的狀態與延遲，選擇sentinel時也不會保證將擁有最新數據的slave提高爲master。

新部署的slave在同步完成前沒有數據

新部署的slave，同master鏈接後，master生成一個rdb文件傳輸給slave，slave加載其中的數據。在這個過程當中，slave是能夠對外訪問的，致使這個期間請求獲取的結果都是不存在的。只有在slave收到rdb文件，加載的過程當中，redis沒法對外服務。