來自Redis 做者的見解 —— Twemproxy

 

雖然大量用戶使用Redis節點的大型農場，但從項目自己來看，Redis主要是單實例業務。
 我有很大的計劃與項目一塊兒分發，在某種程度上我再也不評估Redis的任何線程版本：對我來講，從Redis的角度看，核心就像一臺計算機，所以能夠擴展多核或者在一組計算機上的概念是相同的。多個實例是無共享架構。一切都有意義，由於咱們有一個*可信的方式*去碎片:-)

這就是爲何Redis Cluster將成爲2013年Redis的主要焦點，最後，如今Redis 2.6已經出現而且顯示出很是穩定和成熟，如今是專一於Redis Cluster，Redis Sentinel和其餘產品的合適時機。期待已久的複製領域的改進（部分從新同步）。
 但實際狀況是，Redis Cluster還沒有準備就緒，須要數月的工做。咱們的用戶仍然須要對多個實例上的數據進行分片以分配負載，特別是爲了使用許多計算機來爲數據準備大量的RAM。
 到目前爲止惟一的選擇是客戶端分片。客戶端分片具備優點，由於客戶端和節點之間沒有中間層，也沒有請求路由，所以它是一種很是可擴展的設置（基本上是線性可擴展的）。可是，要可靠地實現它須要一些調整，一種使客戶端配置同步的方法，以及具備一致散列支持或其餘分區算法的可靠客戶端的可用性。
 顯然，這方面有一個重大新聞，而且與Twitter有關，其中部署的最大的Redis農場之一剛好爲用戶提供服務時間表。所以，我在博客文章中談到的項目來自Twitter開源部門並不奇怪。

Twemproxy
---

Twemproxy是一個支持Memcached ASCII協議的快速單線程代理，最近是Redis協議：

https://github.com/twitter/twemproxy

它徹底用C語言編寫，並根據Apache 2.0許可證受權。
該項目適用於Linux，AFAIK沒法在OSX上編譯，由於它依賴於epoll API。

我使用個人Ubuntu 12.04桌面進行了測試。
 可是，我仍然沒有說任何有用的東西。其實是什麼twemproxy？（注意：我將專一於Redis部分，但項目也可以爲memcached作一樣的事情）。

1）它做爲客戶端和許多Redis實例之間的代理。
2）它可以在配置的Redis實例之間自動分片數據。
3）它支持具備不一樣策略和散列函數的一致散列。
 Twemproxy的優勢是它能夠配置爲在發生故障時禁用節點，並在一段時間後重試，或者堅持指定的鍵 - >服務器映射。這意味着當Redis用做數據存儲（禁用節點彈出）時，以及當Redis用做緩存時，它既適用於分割Redis數據集，也適用於廉價的節點彈出（如簡單，不如質量差）高可用性。
 這裏的底線是：若是啓用節點彈出，當節點出現故障時，數據可能會終止到其餘節點，所以沒法保證一致性。另外一方面，若是禁用節點彈出，則須要設置每一個實例的高可用性設置，例如使用Redis Sentinel自動故障轉移。

安裝
---
 在深刻了解項目功能以前，我有一個好消息，在Linux上構建它是微不足道的。好吧，不像Redis那麼微不足道，可是......你只須要遵循這些簡單的步驟：

apt-get install automake
apt-get install libtool
git clone git：//github.com/twitter/twemproxy.git
cd twemproxy
autoreconf -fvi
./configure --enable-debug = log
使
src / nutcracker -h
 配置也很是簡單，項目github頁面中有足夠的文檔能夠得到順暢的初體驗。例如，我使用瞭如下配置：

redis1：
  聽：0.0.0.0：9999
  redis：是的
  hash：fnv1a_64
  分佈：ketama
  auto_eject_hosts：true
  超時：400
  server_retry_timeout：2000
  server_failure_limit：1
  服務器：
   - 127.0.0.1:6379:1
   - 127.0.0.1:6380:1
   - 127.0.0.1:6381:1
   - 127.0.0.1:6382:1

redis2：
  聽：0.0.0.0：10000
  redis：是的
  hash：fnv1a_64
  分佈：ketama
  auto_eject_hosts：false
  超時：400
  服務器：
   - 127.0.0.1:6379:1
   - 127.0.0.1:6380:1
   - 127.0.0.1:6381:1
   - 127.0.0.1:6382:1

基本上，第一個集羣配置了節點彈出，第二個集羣配置爲配置實例中的靜態映射。
 最棒的是，您能夠同時擁有多個可能涉及相同主機的設置。可是對於生產，我發現更適合使用多個實例來使用多個核心。

單點故障？
---

另外一個很是有趣的事實是，實際上，使用此設置並不意味着您只有一個故障點，由於您能夠運行多個twemproxy實例並讓您的客戶端鏈接到第一個可用的實例。
 基本上你用twemproxy作的是將分片邏輯與你的客戶端分開。此時，基本客戶端將執行該操做，分片將由代理處理。

分區恕我直言是一種簡單但安全的方法。
 目前，Redis羣集不可用，我想說，對於今天想要一羣Redis實例的大多數用戶來講，這是一種方法。可是要先閱讀有關限制的內容，以避免太興奮;）

限制
---
 我認爲twemproxy作得對，不支持多個鍵命令和事務。目前，AFAIK比Redis Cluster更嚴格，若是全部命令都是相同的密鑰，則容許使用MULTI / EXEC塊。

但恕我直言，這是可行的方式，分發您能夠有效分發的子集，並儘早將其做爲設計挑戰，而不是將大量資源投入到試圖聚合來自多個實例的數據的「正常工做」實現中可是，一旦你開始出現嚴重負荷，因爲太大的恆定時間來移動數據，這幾乎不會足夠快。
 可是，對具備多個鍵的命令有一些支持。MGET和DEL處理正確。有趣的是，MGET將在不一樣服務器之間拆分請求，並將回覆做爲單個實體返回。即便我沒有使用此功能得到正確的性能數字，這也很酷（見下文）。
 不管如何，不​​支持多鍵命令和事務這意味着twemproxy不適合全部人，就像Redis Cluster自己同樣。特別是由於顯然不支持EVAL（我認爲它們應該支持它！它是微不足道的，EVAL被設計爲在代理中工做，由於鍵名是明確的）。

能夠改進的事情
---
 錯誤報告並不老是很好。發送不受支持的命令會關閉鏈接。一樣，從redis-cli發送一個「GET」並不會報告有關參數數量錯誤的任何錯誤，但會永久掛起鏈接。

可是，服務器的其餘錯誤會正確傳遞給客戶端：

redis metal：10000>獲取清單
（錯誤）WRONGTYPE對持有錯誤值的鍵的操做
 我但願看到的另外一件事是支持自動故障轉移。有不少選擇：
 1）twemproxy已經可以監視實例錯誤，計算錯誤數量，並在檢測到足夠的錯誤時彈出節點。好吧，遺憾的是它沒法將從屬節點做爲替代方案，而不是彈出節點在發送SLAVE OF NOONE命令後當即使用備用節點。這也將把它變成HA解決方案。

2）或者，若是可以與Redis Sentinel協同工做，我會很高興，若是發生故障轉移，請按期檢查Sentinel配置以升級服務器表。

3）另外一種方法是提供一種熱配置twemproxy的方法，以便在故障轉移時Sentinel能夠儘快切換代理的配置。

有不少選擇，但基本上，對HA的一些支持可能很大。

表演
---
 這件事很快。真的很快，幾乎與直接與Redis交談同樣快。我會說你最差的表現會減掉20％。

我惟一的表演問題是，當命令在實例之間分配時，恕我直言MGET可使用一些改進。
 畢竟，若是代理在它和全部Redis實例之間有類似的延遲（極可能），若是同時發送MGET，則回覆可能會同時到達代理。所以，當我針對單個實例運行MGET時，我指望看到與MGET幾乎相同的數字，但我每秒只得到50％的操做。也許如今是重建答覆的時候了，我不肯定。

結論
---

這是一個很棒的項目，因爲Redis Cluster還沒有出現，我強烈建議Redis用戶試一試。
 就我的而言，我要將它連接到Redis項目網站的某個可見位置。我認爲這裏的Twitter人員經過他們的項目爲Redis自己提供了一些真正的價值，因此......

獎勵！