Twemproxy 概述

Twemproxy（又稱為nutcracker）是一個輕量級的Redis和Memcached代理，主要用來減少對後端快取伺服器的連線數。Twemproxy是由Twitter開源出來的快取伺服器叢集管理工具，主要用來彌補Redis/Memcached 對叢集（cluster）管理的不足。

antirez（Redis作者）寫過一篇對twemproxy的介紹，他認為twemproxy是目前Redis 分片管理的最好方案，雖然antirez的Redis cluster正在實現並且對其給予厚望，但從現有的cluster實現上還是認為cluster除了增加Redis複雜度，對於叢集的管理沒有twemproxy來的輕量和有效。

Twemproxy特性

• 輕量級、快速
• 保持長連線
• 減少了直接與快取伺服器連線的連線數量
• 使用 pipelining 處理請求和響應
• 支援代理到多臺伺服器上
• 同時支援多個伺服器池
• 自動分片資料到多個伺服器上
• 實現完整的 memcached 的 ASCII 和再分配協議
• 通過 yaml 檔案配置伺服器池
• 支援多個雜湊模式，包括一致性雜湊和分佈
• 能夠配置刪除故障節點
• 可以通過埠監控狀態
• 支援 linux, *bsd,os x 和 solaris

功能

• 通過代理的方式減少快取伺服器的連線數。
• 自動在多臺快取伺服器間共享資料。
• 通過不同的策略與雜湊函式支援一致性雜湊。
• 通過配置的方式禁用失敗的結點。
• 執行在多個例項上，客戶端可以連線到首個可用的代理伺服器。
• 支援請求的流式與批處理，因而能夠降低來回的消耗。

叢集架構

Twemproxy 安裝

1.編譯安裝：

autoconf下載地址：http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
twemproxy下載地址：https://codeload.github.com/twitter/twemproxy/zip/master
twemproxy的安裝要求autoconf的版本在2.64以上，否則提示"error: Autoconf version 2.64 or higher is required"。

查詢舊版本autoconf，並且解除安裝

rpm -qf /usr/bin/autoconf  
rpm -e --nodeps autoconf-2.63   

安裝最新版本

tar zxvf autoconf-2.69.tar.gz 
cd autoconf-2.69 
./configure --prefix=/usr 
make && make install 

編譯安裝twemproxy

unzip twemproxy-master.zip
cd twemproxy-master
autoreconf -fvi
./configure --prefix=/usr/local/twemproxy
make -j 8
make install

設定環境變數：

 echo "PATH=$PATH:/usr/local/twemproxy/sbin/" >> /etc/profile
 source /etc/profile

2.建立相關目錄（存放配置檔案和pid檔案）

cd /usr/local/twemproxy
mkdir run conf

3.新增proxy配置檔案

vim /usr/local/twemproxy/conf/nutcracker.yml

twemproxy命令列選項：

Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
[-c conf file] [-s stats port] [-a stats addr]
[-i stats interval] [-p pid file] [-m mbuf size]

-h, –help : 檢視幫助文件，顯示命令選項
-V, –version : 檢視nutcracker版本
-t, –test-conf : 測試配置指令碼的正確性
-d, –daemonize : 以守護程序執行
-D, –describe-stats : 列印狀態描述
-v, –verbosity=N : 設定日誌級別 (default: 5, min: 0, max: 11)
-o, –output=S : 設定日誌輸出路徑，預設為標準錯誤輸出 (default: stderr)
-c, –conf-file=S : 指定配置檔案路徑 (default: conf/nutcracker.yml)
-s, –stats-port=N : 設定狀態監控埠，預設22222 (default: 22222)
-a, –stats-addr=S : 設定狀態監控IP，預設0.0.0.0 (default: 0.0.0.0)
-i, –stats-interval=N : 設定狀態聚合間隔 (default: 30000 msec)
-p, –pid-file=S : 指定程序pid檔案路徑，預設關閉 (default: off)
-m, –mbuf-size=N : 設定mbuf塊大小，預設16384 bytes

啟動twemproxy服務

檢測配置檔案:

./sbin/nutcracker -t
nutcracker: configuration file 'conf/nutcracker.yml' syntax is ok

注意：預設檢查命令會檢查所在路徑的conf下面的nutcracker.yml檔案。

啟動命令：

./sbin/nutcracker -d -c /usr/local/twemproxy/conf/nutcracker.yml -p /usr/local/twemproxy/run/redisproxy.pid -o /usr/local/twemproxy/run/redisproxy.log

檢視是否啟動成功：

ps -ef|grep nutcracker

Twemproxy 配置

Twemproxy 通過YAML檔案配置，例如：

alpha:
  listen: 0.0.0.0:22121
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers: --兩臺redis伺服器的地址和埠
   - 10.23.22.240:6379:1   
   - 10.23.22.241:6379:1

說明：

listen
twemproxy監聽地址，支援UNIX域套接字。

hash
可以選擇的key值的hash演算法：

• one_at_a_time
• md5
• crc16
• crc32 (crc32 implementation compatible with libmemcached)
• crc32a (correct crc32 implementation as per the spec)
• fnv1_64
• fnv1a_64，預設選項
• fnv1_32
• fnv1a_32
• hsieh
• murmur
• jenkins

hash_tag
hash_tag允許根據key的一個部分來計算key的hash值。hash_tag由兩個字元組成，一個是hash_tag的開始，另外一個是hash_tag的結束，在hash_tag的開始和結束之間，是將用於計算key的hash值的部分，計算的結果會用於選擇伺服器。

例如：如果hash_tag被定義為”{}”，那麼key值為"user:{user1}:ids"和"user:{user1}:tweets"的hash值都是基於”user1”，最終會被對映到相同的伺服器。而"user:user1:ids"將會使用整個key來計算hash，可能會被對映到不同的伺服器。

distribution
存在ketama、modula和random3種可選的配置。其含義如下：

• ketama，一致性hash演算法，會根據伺服器構造出一個hash ring，併為ring上的節點分配hash範圍。ketama的優勢在於單個節點新增、刪除之後，會最大程度上保持整個群集中快取的key值可以被重用。
• modula，根據key值的hash值取模，根據取模的結果選擇對應的伺服器；
• random，無論key值的hash是什麼，都隨機的選擇一個伺服器作為key值操作的目標；

timeout

單位是毫秒，是連線到server的超時值。預設是永久等待。

backlog
監聽TCP 的backlog（連線等待佇列）的長度，預設是512。

preconnect
是一個boolean值，指示twemproxy是否應該預連線pool中的server。預設是false。

redis
是一個boolean值，用來識別到伺服器的通訊協議是redis還是memcached。預設是false。

server_connections
每個server可以被開啟的連線數。預設，每個伺服器開一個連線。

auto_eject_hosts
是一個boolean值，用於控制twemproxy是否應該根據server的連線狀態重建群集。這個連線狀態是由server_failure_limit閥值來控制。
預設是false。

server_retry_timeout
單位是毫秒，控制伺服器連線的時間間隔，在auto_eject_host被設定為true的時候產生作用。預設是30000 毫秒。

server_failure_limit
控制連線伺服器的次數，在auto_eject_host被設定為true的時候產生作用。預設是2。

servers
一個pool中的伺服器的地址、埠和權重的列表，包括一個可選的伺服器的名字，如果提供伺服器的名字，將會使用它決定server的次序，從而提供對應的一致性hash的hash ring。否則，將使用server被定義的次序。

連線twemproxy

和連線redis 一摸一樣，只是埠換成了22121:

redis-cli -p 22121
127.0.0.1:22121> get kin
"kin"
127.0.0.1:22121> set kin king
OK
127.0.0.1:22121> get kin
"king"

Twemproxy 監控

Twemproxy 監控埠預設為22222，並每隔30s收集一次資訊。

nutcracker --describe-stats

報告的資訊如下：

pool stats:
  client_eof          "# eof on client connections"
  client_err          "# errors on client connections"
  client_connections  "# active client connections"
  server_ejects       "# times backend server was ejected"
  forward_error       "# times we encountered a forwarding error"
  fragments           "# fragments created from a multi-vector request"

server stats:
  server_eof          "# eof on server connections"
  server_err          "# errors on server connections"
  server_timedout     "# timeouts on server connections"
  server_connections  "# active server connections"
  requests            "# requests"
  request_bytes       "total request bytes"
  responses           "# responses"
  response_bytes      "total response bytes"
  in_queue            "# requests in incoming queue"
  in_queue_bytes      "current request bytes in incoming queue"
  out_queue           "# requests in outgoing queue"
  out_queue_bytes     "current request bytes in outgoing queue"

效能測試

用redis自帶的redis-benchmark進行效能測試：

set 測試：

twemproxy:

redis-benchmark -h10.23.22.240-p 22121 -c 100 -t set -d 100

原生redis:

redis-benchmark -h10.23.22.241-p 6379 -c 100 -t set -d 100

Get測試

twemproxy:

redis-benchmark-h10.23.22.240-p22121-c100-tget-d100

原生redis:

redis-benchmark-h10.23.22.241-p6379-c100-t get-d100

Twemproxy優缺點

優缺點：

1.前端使用 Twemproxy 做代理，後端的 Redis 資料能基本上根據 key 來進行比較均衡的分佈。

2.後端一臺 Redis 掛掉後，Twemproxy 能夠自動摘除。恢復後，Twemproxy 能夠自動識別、恢復並重新加入到 Redis 組中重新使用。

注意點：

1.Redis 掛掉後，後端資料是否丟失依據 Redis 本身的策略配置，與 Twemproxy 基本無關。

缺點：

1.當redis叢集動態新增節點時，Twemproxy 需要重啟才能生效,並且資料不會自動重新 Reblance，需要人工單獨寫指令碼來實現。

2.效能上的損耗，作者是說最差情況下，效能損耗不會多於20%。

3.單點問題，需要使用keepalived vip做高可用。