理解redis高可用方案


理解並從頭搭建redis集群

部分開發人員工作當中只是在應用中使用redis,比如用來做數據結果的緩存。而且現在有很多不錯的redis客戶端工具(redisson),基本上可以不用關注redis命令就可以完成相當部分的功能。所以可能會對如下這些問題關注點不夠:

  • 如何容災?即某個redis節點出了問題如何保證服務的高可用性
  • 如何橫向擴容?當數據量特別大時,如何解決單個redis的性能問題
  • 集群至少需要幾台機器?或者幾個redis節點
  • 集群搭建都利用什么技術,哪些工具?

如何容災?

redis提供了主從熱備機制,主服務器的數據同步到從服務器,通過哨兵實時監控主服務器狀態並負責選舉主服務器。當發現主服務器異常時根據一定的算法重新選舉主服務器並將問題服務器從可用列表中去除,最后通知客戶端。主從是一對多的樹型結構,如下圖:

哨兵

哨兵是sentinel的中文名稱,是redis出的一個高可用架構的工具,自身是一個獨立的進程,可以同時監控一個以上的redis集群。

哨兵集群

基於高可用的考慮,哨兵自身也是需要支持集群的,如果只有一個哨兵就會存在單點問題。

哨兵決策

哨兵有一個數量配置,當多少個哨兵同時認為某個主服務不可用時才進行主從切換,比如總共有5個哨兵,當3個哨兵認為服務不可用時才決定做主從切換。這么做可以避免一些誤切換,降低切換成本,比如瞬時的網絡異常等。

如何橫向擴容?

無論是redis還是其它一些數據庫之類的產品,當單節點的數據容量達到一定上限后,服務對外提供的能力會越來越弱。redis在高版本中提供了redis-trib.rb來實現集群功能,也可以使用第三方的工具twemproxy。

去中心化,每個節點都是平等的

redis集群從設計上沒有考慮中心化,這樣可以避免中心節點的單點等問題。每個節點都能掌握整個集群的狀態,連接任意的節點都可以訪問到所有的key,就像單節點的redis一樣。

集群原理圖

自己理解畫的,如有理解不對的地方可以指出。

key與redis節點的關系

引入了hasy solt,中文理解為哈希槽。總共16384個,我們操作的key通過取模算法確認key落在哪個槽上。

HASH_SLOT = CRC16(key) mod 16384

哈希槽與節點之間有一定關系,所以我們就可以將key分配到某個具體的redis節點上了。

詳細的關系可再研究,簡單的比如節點A負責0-5000編號的哈希槽,節點B負責5001-1000

一步一步搭建

開始搭建三主三從的集群,系統是ubuntu,采用redis提供的集群工具redis-trib.rb。

  • 安裝最新redis
  • 創建redis_cluster目錄,並且創建7000到7005這6個目錄
  • 將redis目錄下的redis.conf復制到上面創建的6個目錄中
  • 分別修改redis.conf文件,對6個文件做類似的修改。
port  7000                                       //端口7000       
bind  127.0.0.1                                  //默認ip為127.0.0.1 需要改為其他節點機器可訪問的ip
daemonize    yes                                 //后台運行
pidfile  /var/run/redis_7000.pid                 //pidfile文件對應7000
cluster-enabled  yes                             //開啟集群
cluster-config-file  nodes_7000.conf             //集群的配置
cluster-node-timeout  15000                      //請求超時  默認15秒,可自行設置

bind需要注意的就是需要配置為其它機器可以訪問的ip,否則無論是創建集群還是客戶端連接都會有問題。

  • 啟動6個redis
redis-server redis_cluster/7000/redis.conf
redis-server redis_cluster/7001/redis.conf
redis-server redis_cluster/7002/redis.conf
redis-server redis_cluster/7003/redis.conf
redis-server redis_cluster/7004/redis.conf
redis-server redis_cluster/7005/redis.conf
  • 創建集群
    redis的src目錄下有個redis-trib.rb,將它復制到/usr/local/bin中,然后執行如下腳本:
redis-trib.rb  create  --replicas  1  127.0.0.1:7000 127.0.0.1:7001  127.0.0.1:7002 127.0.0.1:7003  127.0.0.1:7004  127.0.0.1:7005

--replicas后面的1代表從服務器的個數,上面可以理解為前面3個為主服務器,后面三個分別做為從服務器,即三對主從。

執行過程中會遇到提示需要安裝ruby,安裝完成之后又會提示安裝 gem redis。

安裝gem redis,折騰了好久,最終發現是因為在國內訪問不了某些網站導致通過apt-get install安裝不成功,最后通過下載源碼的方式安裝成功。

再次執行創建集群的腳本,出現如下提示:

輸入yes,繼續

最少需要多少個主服務器?
可能是基於某些約定,集群約定只有當可用節點數大於半數以上時才具備對外提供服務的能力。首先數量一定是奇數,其實必須大於1,所以最少的主服務器數量為3。

  • 測試集群
    連接客戶端,由於我的所有節點都是在本地,所以不需要輸入ip,但需要加-c的參數。
redis-cli -c -p 7000

連接成功后,增加一個key

set mykey 123

有一行提示語,指向到端口7002,這說明雖然我們連接的是7000的實例,但通過hash算法最終會將key分配到7002的實例上。

再連接7005端口查詢下key,測試下是否任意一個實例都可以查詢到key

get mykey

顯示指向到端口7002

集群需要注意的地方

這塊還未仔細研究,有些命令在集群下是不支持的,待后續求證。

引用

總結

真實環境的部署與單機部署還是差異比較大的,但也不復雜,盡管部分開發人員可能一輩子都不會有機會在線上搭建redis集群,但了解redis的高可用可擴展的方案對設計大型系統還是有比較大的幫助的,也有助於分析解決線上問題。看了上面的這些,對於本文開頭提到的問題就不難理解了。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM