redis HA高可用方案Sentinel和shard

標籤：

1、搭建redis-master、redis-slave以及seninel哨兵監控

 

在最小配置：master、slave各一個節點的情況下，不管是master還是slave down掉一個，“完整的”讀/寫功能都將受影響，這在生產環境中顯然不能接受。幸好redis提供了sentinel（哨兵）機制，通過sentinel模式啟動redis後，自動監控master/slave的運行狀態，基本原理是：心跳機制+投票裁決

每個sentinel會向其它sentinal、master、slave定時發送訊息，以確認對方是否“活”著，如果發現對方在指定時間（可配置）內未回應，則暫時認為對方已掛（所謂的“主觀認為宕機” Subjective Down，簡稱SDOWN）。

若“哨兵群”中的多數sentinel，都報告某一master沒響應，系統才認為該master"徹底死亡"(即：客觀上的真正down機，Objective Down，簡稱ODOWN)，通過一定的vote演算法，從剩下的slave節點中，選一台提升為master，然後自動修改相關配置

 

 

最小化的sentinel設定檔為：

 

 

[html] view plain copy  print?

1. 1 port 26389  
2. 2   
3. 3 dir ./tmp  
4. 4   
5. 5 sentinel monitor mymaster 127.0.0.1 6379 1  
6. 6 sentinel down-after-milliseconds mymaster 5000  
7. 7 sentinel parallel-syncs mymaster 1  
8. 8 sentinel failover-timeout mymaster 15000  

 

 

 

第1行，指定sentinel使用的連接埠，不能與redis-server運行執行個體的連接埠衝突

第3行，指定工作目錄

第5行，顯示監控master節點10.6.144.155，master節點使用連接埠7030，最後一個數字表示投票需要的"最少法定人數"，比如有10個sentinal哨兵都在監控某一個master節點，如果需要至少6個哨兵發現master掛掉後，才認為master真正down掉，那麼這裡就配置為6，最小配置1台master，1台slave，在二個機器上都啟動sentinal的情況下，哨兵數只有2個，如果一台機器物理掛掉，只剩一個sentinal能發現該問題，所以這裡配置成1，至於mymaster只是一個名字，可以隨便起，但要保證5-8行都使用同一個名字

第6行，表示如果5s內mymaster沒響應，就認為SDOWN

第8行，表示如果15秒後,mysater仍沒活過來，則啟動failover，從剩下的slave中選一個升級為master

第7行，表示如果master重新選出來後，其它slave節點能同時並行從新master同步緩衝的台數有多少個，顯然該值越大，所有slave節點完成同步切換的整體速度越快，但如果此時正好有人在訪問這些slave，可能造成讀取失敗，影響面會更廣。最保定的設定為1，只同一時間，只能有一台幹這件事，這樣其它slave還能繼續服務，但是所有slave全部完成緩衝更新同步的進程將變慢。

另：一個sentinal可同時監控多個master，只要把5-8行重複多段，加以修改即可。

各自啟動redis主備和sentinal哨兵，查看redis的master

 

./redis-cli -p 26389 sentinel masters 可通過該命令查看當前的master節點情況

 

類比當master掛掉，是否slave switch為master.

 

切換成功,將掛掉master啟起來，是否該redis變幻為slave.

 

2、sentinel和shard redis保證redis 叢集的高可用。

Sentinel&Jedis看上去是個完美的解決方案，這句話只說對了一半，在無分區的情況是這樣，但我們的應用使用了資料分區-sharing，資料被平均分布到4個不同的執行個體上，每個執行個體以主從結構部署，Jedis沒有提供基於Sentinel的ShardedJedisPool，也就是說在4個分區中，如果其中一個分區發生主從切換，應用所使用的ShardedJedisPool無法獲得通知，所有對那個分區的操作將會失敗。 
本文提供一個基於Sentinel的ShardedJedisPool，能及時感知所有分區主從切換行為，進行串連池重建..........

 

 

3\監控..

 

目前針對redis的監控比較少見，主要有redis-live、dredis等。但這些工具對redis效能消耗比較嚴重，即時監控比較困難。

redis的監控可以簡單分為安全監控和效能監控。安全監控可以通過redissentinel的輸出日誌判斷Master和Slave的狀態；效能監控需要收集redis的績效參數進行評估。因此二者並不衝突，通過shell指令碼可以實現輕量級的監控，缺點是沒有可視化的即時圖表。

1、安全監控

Redis sentinel的輸出日誌簡潔而且內容很豐富，包含redis的即時狀態、故障切換時間以及sentinel自身的狀態，並且針對故障消除也有詳細的記錄。通過對sentinel日誌挖掘，找出故障時刻進行及時警示，並通知管理員。

由於sentinel預設不啟用日誌記錄，可以通過以下方法記錄日誌：

啟動輸入日誌:

src/redis-sentinel sentinel.conf >>sentinel.log &

redis HA高可用方案Sentinel和shard