[轉載] Redis集羣搭建最佳實踐

轉載自http://blog.csdn.net/sweetvvck/article/details/38315149?utm_source=tuicool

要搭建Redis集羣，首先得考慮下面的幾個問題;

 

Redis集羣搭建的目的是什麼？或者說爲何要搭建Redis集羣？

 

Redis集羣搭建的目的其實也就是集羣搭建的目的，全部的集羣主要都是爲了解決一個問題，橫向擴展。

在集羣的概念出現以前，咱們使用的硬件資源都是縱向擴展的，可是縱向擴展很快就會達到一個極限，單臺機器的Cpu的處理速度，內存大小，硬盤大小沒辦法一直知足需求，並且機器縱向擴展的成本是至關高的。集羣的出現就是可以讓多臺機器像一臺機器同樣工做，實現了資源的橫向擴展。

 

Redis是內存型數據庫，當咱們要存儲的數據達到必定程度時，單臺機器的內存知足不了咱們的需求，搭建集羣則是一種很好的解決方案。

 

那麼如何可以讓多臺機器上的Redis可以像一臺機器上的Redis同樣工做呢？

 

須要解決如下三個問題;

1.對外暴露一個訪問節點

2.請求分片（sharding）

3.分片要合理（分片均勻，相同的請求要分配到一樣的redis節點）

 

首先，要對外暴露一個訪問節點，後面可能有多臺redis再工做;咱們很容易想到的就是代理（Proxy），對於客戶端只須要知道代理，經過代理來和後臺的多臺redis交互。

 

第二個問題可使用hash算法解決，將請求的某個key取hash值，對redis個數取餘，來分配的不一樣的redis上；然而這麼作不能知足第三點中的相同的請求要分配到一樣的redis中。在這種狀況下一致性哈希可以完美的解決這個問題，一致性哈希能夠將redis的節點經過hash算法分佈再一個2 ³² 個節點的圓環上，將請求的key用一樣的hash算法映射到這個圓環上，而後在key值的節點順時針尋找最近的redis節點，這樣就保證了一致性；詳細介紹能夠參考： http://blog.csdn.net/sparkliang/article/details/5279393 。

 

若是讓我來實現redis集羣的話，我會採用zookeeper加上一個redis守護程序加上一致性hash算法來實現。不過twicer的大神們已經實現並開源了一個redis集羣方案，我就不重複製造輪子了；來看看這個全球最大的redis集羣使用者之一的大神們實現的 twemproxy (nutcracker)有哪些特性。

 

Twemproxy除了能夠做爲redis的代理，它一樣支持memerycached的ASCII協議。我這裏主要了解Twemproxy在redis集羣上的解決方案。Twemproxy除了完美的解決了上面的三個問題（一樣採用了一致性hash算法），還有一個重要的特色；它支持

node ejection，若是使用redis當緩存，不是很注重數據的一致性的話，開啓node ejection能夠在集羣中某一臺redis掛掉的時候將其送集羣列表中移除，達到高可用性。若是redis集羣作爲數據存儲的話，或者很注重數據的一致性，則能夠禁用node jection，但此時須要使用其餘方法實現高可用性，好比redis sentiel。Twemproxy的詳細介紹能夠看看這篇文章： http://antirez.com/news/44 ；Twemproxy項目Github地址：https://github.com/twitter/twemproxy 。

 

廢話說了這麼多，來看看怎麼安裝twemproxy，搭建redis集羣吧

 

首先按照github提示的步驟安裝twemproxy：

To build nutcracker from source with debug logs enabled and assertions disabled:

若是顯示幫助信息，則表示安裝成功；

接下來編輯配置信息，找一個本身喜歡的目錄，建立配置文件，後綴爲yml，如twemproxy.test.yml;填入以下信息：
$ git clone git@github.com:twitter/twemproxy.git
$ cd twemproxy
$ autoreconf -fvi
$ ./configure --enable-debug=log
$ make

依次輸入上面的命令，而後輸入：
$ src/nutcracker -h

alpha:
  listen: 127.0.0.1:55555
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 30000
  server_failure_limit: 1
  servers:
    - 192.168.1.10:6379:1
    - 192.168.1.7:6379:1

注意縮進，不然將沒法啓動twenproxy。
其中listen：表示代理的ip以及端口號，是暴露給客戶端使用的；hash: 表示使用哪一種hash方法，twemproxy提供了多種方式，具體能夠看github介紹；distribution表示分配模式，有三種選擇：ketama， modula，random；auto_reject_hosts: 就是上面所說的，自動移除失敗的節點；redis: 表示使用的是redis集羣，剩下的配置很簡單就不一一介紹了......
經過如此簡單的配置以後，執行./src/nutcracker -c ./conf/nutcracker.test.yml（這裏使用本身的安裝路徑和配置文件路徑） 就啓動了twemproxy， 客戶端只須要經過redis-cli就能鏈接上proxy，使用方法和redis徹底同樣（但不是全部命令都支持）。

這樣redis的集羣就搭好了，是否是簡單到爆？不過不要開心得太早，twemproxy也有它的不足之處。

1.不支持事務以及批量操做;
2.相較於直接訪問redis性能有所損耗;

雖然twemproxy有上述缺點，單相較於起帶來的好處簡直不值一提！但也說明它不適用於全部狀況。

Redis集羣還有不少種搭建方式，其官方的cluster一直處於beta狀態，相信瞭解了twemproxy後，你們會發現它是如今最好的選擇！