概述

實際業務場景中單點 Redis 容量、并發都是有限的，所以有 Redis Cluster 的需求。

但是官方的 Redis Cluster 一再跳票，還不可用。

只好先使用最簡單的方式：Proxy。有很多可選，但在大范圍生產使用的， Twitter 開源的 Twemproxy  看起來是個理想的選擇 – https://github.com/twitter/twemproxy 。

我們期望的目標：

• tag/alias 緩存集群（現在單點容量支持越來越不夠）
• 數據統計時高并發緩存

下面的文章內容也是基于實際生產需要而進行的一系列測試.

測試環境說明

本次測試的機器都是虛擬機，對應的母機配置為 Dell R710   Intel(R) Xeon(R) CPU       E5606  @ 2.13GHz  2CPU(單CPU 4核)  32G內存，上面安裝了4臺虛擬機，配置分別如下：

虛擬機系統： CentOS release 6.3 (Final)    

Redis版本：2.6.16

Twemproxy版本：nutcracker-0.2.4

部署示意圖

下面的測試都是根據上面的配置不同組合來進行測試得出對應的結論。

測試工具：Redis Benchmark.

測試結論

功能

1. 前端使用 Twemproxy 做代理，后端的 Redis 數據能基本上根據 key 來進行比較均衡的分布。
2. 后端一臺 Redis 掛掉后，Twemproxy 能夠自動摘除?；謴秃?，Twemproxy 能夠自動識別、恢復并重新加入到 Redis 組中重新使用。
3. Redis 掛掉后，后端數據是否丟失依據 Redis 本身的策略配置，與 Twemproxy 基本無關。
4. 如果要新增加一臺 Redis，Twemproxy 需要重啟才能生效；并且數據不會自動重新 Reblance，需要人工單獨寫腳本來實現。
5. 如同時部署多個 Twemproxy，配置文件一致（測試配置為distribution：ketama,modula），則可以從任意一個讀取，都可以正確讀取 key對應的值。
6. 多臺 Twemproxy 配置一樣，客戶端分別連接多臺 Twemproxy可以在一定條件下提高性能。根據 Server 數量，提高比例在 110-150%之間。
7. 如原來已經有 2 個節點 Redis，后續有增加 2 個 Redis，則數據分布計算與原來的 Redis 分布無關，現有數據如果需要分布均勻的話，需要人工單獨處理。
8. 如果 Twemproxy 的后端節點數量發生變化，Twemproxy 相同算法的前提下，原來的數據必須重新處理分布，否則會存在找不到key值的情況。

性能

不管 Twemproxy 后端有幾臺 Redis，前端的單個 Twemproxy 的性能最大也只能和單臺 Redis 性能差不多。

Twemproxy介紹

Twemproxy 也叫 nutcraker。是 Twtter 開源的一個 Redis 和 Memcache 代理服務器，主要用于管理 Redis 和 Memcached 集群，減少與Cache 服務器直接連接的數量。

Twemproxy特性：

• 輕量級、快速
• 保持長連接
• 減少了直接與緩存服務器連接的連接數量
• 使用 pipelining 處理請求和響應
• 支持代理到多臺服務器上
• 同時支持多個服務器池
• 自動分片數據到多個服務器上
• 實現完整的 memcached 的 ASCII 和再分配協議
• 通過 yaml 文件配置服務器池
• 支持多個哈希模式，包括一致性哈希和分布
• 能夠配置刪除故障節點
• 可以通過端口監控狀態
• 支持 linux, *bsd,os x 和 solaris

Twemproxy安裝配置參考官網：https://github.com/twitter/twemproxy 或 附后的 Reference。

啟動命令：

$/usr/local/twemproxy/sbin/nutcracker -d -c /usr/local/twemproxy/etc/test.yml -i 2000 -o logs/nutcracker.log

或者修改源碼的 scripts 中的 ini 代碼以 service 方式啟動。

運行中如果需要查看運行狀態使用下面方式，結果為json格式，需要自己格式化。

1.web界面運行啟動服務的http://ip:22222查看，如本次測試查看url：http://192.168.2.68:22222/

2.使用nc命令查看 Twemproxy 狀態語句：

$nc 192.168.2.68 22222|python -mjson.tool

Twemproxy支持命令測試

源碼的scripts中包含一些腳本可以進行基本功能測試，如下：

測試不支持的幾個命令： restore decr  decrby

如果生產環境中使用的話，建議先檢查是否有無法使用的命令后在決定使用。

Twemproxy 和單機 Redis 對比測試

測試方法：使用 Redis 自帶壓力測試工具 redis-benchmark 測試2-3次，取其中比較好的結果。

注：測試本機上面的 Redis 都是在其他客戶端上面執行，避免由于不通過網絡導致測試不準確.另外每次運行結果都有不同差距。

執行命令類似如下：

$/usr/local/bin/redis-benchmark -h 192.168.2.68 -p 10000 -c 100 -q

Twmemproxy 配置的后端 Redis 信息如下：

從自帶的壓力測試工具看，基本上 Twemproxy 的性能和單臺 Redis 服務基本差不多。后端自帶 Redis 只是為數據更好的split(由于從實際統計信息看看，壓力測試實際上只訪問了后端的其中某一臺redis服務，故這個結果也屬于正常)

Twemproxy后端接入不同 Redis 數量測試對比

本測試主要驗證 Twemproxy 后端接入不同 Redis 數量后，測試的ops比較，結果只能作為參考意義。

設置測試方式，Twemproxy 的分布方式設置為 hash，測試對比如上圖?；旧虾蛦闻_redis性能差不多。實際看后端也只訪問一臺redis。

分布參數設置為random模式。可以比較均勻分布。

測試類似命令：

/usr/local/redis/bin/redis-benchmark -h 192.168.2.65 -p 9999 -t SET  -n 1000000 -c 100 -q

目前環境： 2臺機器都搭建 Twemproxy Server，每臺端口為9999，19999，29999

目前6臺 Redis 分別測試的結果為:

(31438.63+32406.51+37087.86+26886.78+34291.20+32544.67)/6=32442.6083

可以近似看成是 Redis 的單臺性能。

測試方式：

1.后端 Redis 節點數量不變，不同 Twemproxy server 測試及多個同時運行測試結果如下：

從上面數據可以看出，單臺最多也只能達到單個 Redis 的性能；2個節點運行性能增加大概110%左右。4個 server 運行，性能大概增加了123%，6個 server 接入運行160%。

2.前端使用1個 Twemproxy server，后端 Redis 數量分別為2，3，4，5，6來進行壓力測試，看測試結果,測試數據如下：

從數據可以看出，后端節點數量與 Twemproxy 的性能基本無關，最大性能也就是單個 Redis 的性能。

Twemproxy功能測試

1.Twemproxy 正常訪問，后端 Redis 掛掉一臺，前端訪問是否正常;后端 Redis 掛掉的恢復，不重啟 Twemproxy，觀察恢復的數據是否有繼續增加

從測試結果看，基本正常，由于使用命令/usr/local/bin/redis-cli，無法看到錯誤信息，不能確認在中斷瞬間是否有報錯。

從各 Redis 的 keys 數量看，基本可以滿足.測試過程中 Redis 中斷不到1分鐘。從實際數據看只丟失了15個key(總key數量為26W)，可以認為Twemproxy 能夠自動摘掉故障的 Redis 及自動恢復。

2.正常裝載一部分數據，計算后端各 Redis 的 key 分布情況是否均勻

3. Twemproxy 默認使用(distribution: ketama)先使用后端3個節點裝載key數量：300708 ，然后后端節點增加到6個(distribution: ketama)，在裝載300708個 key 值，對比分布趨勢：

相同算法下，后續的數據都可以正常提取查找，但是原來已經在 Redis 的數據信息，部分找不到。具體數據如下：

從上面可以看出，增加后端 Redis 后，Twemproxy 使用計算新的算法 key 保存的值。從缺省算法的成功率上可以看出，找不到的比例和增加的新的 Redis 點有一定關系(剛好大概一半找不到。我們增加了1倍的節點)

數據一致性測試

測試方法，分別開3個 Twemproxy server(port)，分布格式為 ketama，ketama，random。從其中一個 ketama 分布的插入。然后分別從其他2個不同類型的 server 讀取，判斷讀取值是否正確。

裝載數據共300708記錄，然后使用 get 方式讀取，對應的 key 還是從源文件讀取 key?？梢钥吹剑愋蜑?ketama 的2臺 server 都可以全部獲取到對應的key值，而 random 有2/3獲取不到(總記錄300708，能獲取到key的記錄:100347).

Reference

在測試中參考的網絡部分資料，本文章中部分內容也有引用，在此感謝！

• 官網：https://github.com/twitter/twemproxy
• 翻譯介紹： http://1.breakwang.sinaapp.com/?p=78
• 安裝測試：http://blog.mkfree.com/posts/515bce9d975a30cc561dc360#
• Redis : http://redis.io/

 轉自 http://blog.jpush.cn/redis-twemproxy-benchmark/