理解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

集羣須要注意的地方

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

引用

• http://www.cnblogs.com/wuxl360/p/5920330.html
• http://www.javashuo.com/article/p-vguqgocn-gw.html
• http://blog.csdn.net/lifeiaidajia/article/details/45370377

總結

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