redis客戶端實現高可用讀寫分離的方式詳解
背景
(1) redis單機的讀寫性能輕松上大幾萬,不過線上環境不會隻部署光禿禿的一個節點,還是會配合 sentinel 再部署一個 slave作為高可用節點的;
但是standby的slave節點是不對外提供服務端的,一定程度上造成瞭浪費資源
(2) 當業務不斷發展,原來單節點緩存的數據(如,商品信息緩存、配置信息等)的查詢qps不斷升高(寫qps增長不多),突破十幾萬、幾十萬的的時候,此時一個節點就扛不住瞭,我們就需要增加幾個redis slaves節點來分擔這些查詢的壓力 也就是讀寫分離
但是,常用的 redis 客戶端jedis並不支持讀寫分離能力
實現方式
(1) 從配置中心獲取 master 和 slaves 的連接信息,分別初始化好一個連接master的寫連接池和一組slave的讀連接池
(2) 將命令進行分類:執行寫命令則從 master的連接池取連接然後執行,如果是讀命令則從slave的連接池中取出連接執行
可能有多個slave節點,可以按照一定的策略進行負載均衡(權重、隨機、輪詢…etc) 從其中一個 slave節點的連接池獲取連接
大概長這樣:
高可用版本
前面的實現方式正常情況下是可以的
但是:
(1) 如果運行期間 master掛瞭怎麼辦? 如何自動 failover 切換?
(2) 如果流量突增,需要動態擴容一個或多個 slave節點,如何動態生效?
那就不能從配置文件取master和slaves的 ip+port 瞭,得從redis ha的組件去動態獲取 當前master 和可用slave列表的節點信息 => sentinel
1.初始化
向 sentinel 發送命令獲取master和slaves的節點信息
//獲取當前masterName標識的當前master節點信息,哨兵可監控多個 mater ha,所以要用<masterName>區分 SENTINEL get-master-addr-by-name <masterName> //獲取可用的slaves列表信息 SENTINEL slaves <masterName>
拿到連接後,繼續用開頭的方式去創建連接池就行瞭
2. 動態failover、擴容
初始化完畢後,在運行期間master節點,和slaves還是可能變化的, 如
(1) master故障、網絡分區,sentinel 提升一個slave為新的master
(2) 新增slave節點應對突增流量
我們如何能不重啟客戶端的情況下,動態切換?
sentinel 在進行master切換、slave變更等操作的時候都會向對應的 channel 發佈事件,我們可以基於這些事件感知到相應的變化
參考: https://redis.io/topics/sentinel
2.1 failover切換 master
當 sentinel 進行master failover切換的時候,它會向channel: switch-master 發送通知,我們在客戶端訂閱這個channel,收到事件後,重新進行初始化的步驟即可
2.2 擴容slave
當新的 slave 節點加入, sentinel 感知到則會向channel: +slave 發佈事件,我們監聽到後,重新獲取slaves節點信息重建slaves的連接池就可以瞭(這邊不涉及master的變化)
總結
基於 sentienl 獲取和動態感知 master、slaves節點信息的變化,我們的讀寫分離客戶端就能具備高可用+動態擴容感知能力瞭;
到此這篇關於redis客戶端實現高可用讀寫分離的文章就介紹到這瞭,更多相關redis讀寫分離內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- 解析高可用Redis服務架構分析與搭建方案
- 2021年最新Redis面試題匯總(3)
- Redis實現主從復制方式(Master&Slave)
- 一文掌握Redis的三種集群方案(小結)
- redis哨兵常用命令和監控示例詳解