Redis 存储分片之代理服务Twemproxy 测试
Redis 存儲分片之代理服務Twemproxy 測試
轉載自：http://blog.jpush.cn/redis-twemproxy-benchmark/
概述
實際業務場景中單點 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臺虛擬機，配置分別如下：
序號 | 機器IP | 配置 | 部署服務 | redis服務數量 |
1 | 192.168.2.65 | 4cpu,8GRam | redis,twemproxy | 4個端口分別為(10000,10002,10003,10004) |
2 | 192.168.2.66 | 4cpu,8GRam | redis | 2個端口分別為(10000,10002) |
3 | 192.168.2.67 | 4cpu,8GRam | redis | 2個端口分別為(10000,10002) |
4 | 192.168.2.68 | 4cpu,4GRam | redis,twemproxy | 2個端口分別為(10000,10002) |
虛擬機系統： CentOS release 6.3 (Final)????
Redis版本：2.6.16
Twemproxy版本：nutcracker-0.2.4
部署示意圖
下面的測試都是根據上面的配置不同組合來進行測試得出對應的結論。
測試工具：Redis Benchmark.
?
測試結論
功能
前端使用 Twemproxy 做代理，后端的 Redis 數據能基本上根據 key 來進行比較均衡的分布。
后端一臺 Redis 掛掉后，Twemproxy 能夠自動摘除。恢復后，Twemproxy 能夠自動識別、恢復并重新加入到 Redis 組中重新使用。
Redis 掛掉后，后端數據是否丟失依據 Redis 本身的策略配置，與 Twemproxy 基本無關。
如果要新增加一臺 Redis，Twemproxy 需要重啟才能生效；并且數據不會自動重新 Reblance，需要人工單獨寫腳本來實現。
如同時部署多個 Twemproxy，配置文件一致（測試配置為distribution：ketama,modula），則可以從任意一個讀取，都可以正確讀取 key對應的值。
多臺 Twemproxy 配置一樣，客戶端分別連接多臺 Twemproxy可以在一定條件下提高性能。根據 Server 數量，提高比例在 110-150%之間。
如原來已經有 2 個節點 Redis，后續有增加 2 個 Redis，則數據分布計算與原來的 Redis 分布無關，現有數據如果需要分布均勻的話，需要人工單獨處理。
如果 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中包含一些腳本可以進行基本功能測試，如下：
?
scripts目錄腳本 ? ?
[root@test66 scripts]$ ls -tlh ? ? ? ? ? ? |
從執行結果看，下面命令都可以使用(結合我們常用的命令)
del psetex linsert smove zscore dump set llen spop zunionstore exists setbit lpop srandmember eval expire psetex lpush srem persist setnx lpushx sunion expireat setrange lrange sunionstore expire hdel lrem zadd pttlhexists ltrim zcard ttl hget rpop zcount type hgetall append hincrby rpush zinterstore bitcount hincrbyfloat rpushx zrange get hkeys sadd zrangebyscore getbit hlen scard zrank getrange zrem getset hmset sdiffstore zremrangebyrank incr hset sinter zremrangebyscore incrby hsetnx sinterstore zrevrange incrbyfloat hvals sismember zrevrangebyscore mget lindex smembers zrevrank rpoplpush zincrby hmget sdiff |
測試不支持的幾個命令： 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?-qTwmemproxy 配置的后端 Redis 信息如下：
… ? ? ? ? ? ? |
從自帶的壓力測試工具看，基本上 Twemproxy 的性能和單臺 Redis 服務基本差不多。后端自帶 Redis 只是為數據更好的split(由于從實際統計信息看看，壓力測試實際上只訪問了后端的其中某一臺redis服務，故這個結果也屬于正常)
命令\IP | 2.68:10000 | 2.68:10002 | 2.68:10003 | 2.68:10004 | 2.68:10005 | 2.67:10000 | 2.66:10000 | 2.65:10000 | twemproxy(9999) |
SET | 21231.42 | 21598.27 | 21645.02 | 22026.43 | 21413.28 | 23364.49 | 23584.91 | 23310.02 | 25125.63 |
GET | 26246.72 | 21739.13 | 20661.16 | 20876.83 | 21367.52 | 22831.05 | 23041.47 | 23809.53 | 25510.21 |
LPOP | 20120.72 | 21276.60 | 21367.52 | 17152.66 | 21097.05 | 23474.18 | 23201.86 | 23696.68 | 22075.05 |
SADD | 20449.90 | 21052.63 | 20833.33 | 20876.83 | 21551.72 | 23364.49 | 23094.69 | 23923.44 | 17825.31 |
LPUSH | 26178.01 | 20833.33 | 21413.28 | 20876.83 | 21008.40 | 23809.53 | 23696.68 | 23696.68 | 23148.15 |
LRANGE_100 | 17452.01 | 14534.88 | 14245.01 | 14684.29 | 14144.27 | 15060.24 | 15267.18 | 15408.32 | 15503.88 |
?
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 測試及多個同時運行測試結果如下：
twemproxy server運行數量(port) | 1(A server) | 1(B Server) | 2 | 4 | 6 |
測試結果(/s) | 30278.26 | 32867.71 | 35143.28 | 40176.777 | 52345.5152 |
從上面數據可以看出，單臺最多也只能達到單個 Redis 的性能；2個節點運行性能增加大概110%左右。4個 server 運行，性能大概增加了123%，6個 server 接入運行160%。
2.前端使用1個 Twemproxy server，后端 Redis 數量分別為2，3，4，5，6來進行壓力測試，看測試結果,測試數據如下：
redis節點數 | 2 | 3 | 4 | 5 | 6 |
測試結果(/s) | 34882.1 | 34749.97 | 32296.61 | 32438.04 | 32867.71 |
從數據可以看出，后端節點數量與 Twemproxy 的性能基本無關，最大性能也就是單個 Redis 的性能。
?
Twemproxy功能測試
1.Twemproxy 正常訪問，后端 Redis 掛掉一臺，前端訪問是否正常;后端 Redis 掛掉的恢復，不重啟 Twemproxy，觀察恢復的數據是否有繼續增加
從測試結果看，基本正常，由于使用命令/usr/local/bin/redis-cli，無法看到錯誤信息，不能確認在中斷瞬間是否有報錯。
從各 Redis 的 keys 數量看，基本可以滿足.測試過程中 Redis 中斷不到1分鐘。從實際數據看只丟失了15個key(總key數量為26W)，可以認為Twemproxy 能夠自動摘掉故障的 Redis 及自動恢復。
#初始化redis，各redis中的keys為空 ? ? ? ? ? ? |
2.正常裝載一部分數據，計算后端各 Redis 的 key 分布情況是否均勻
#總共插入26W個key,通過twemproxy的端口操作 ? ? ? ? ? ? |
3. Twemproxy 默認使用(distribution: ketama)先使用后端3個節點裝載key數量：300708 ，然后后端節點增加到6個(distribution: ketama)，在裝載300708個 key 值，對比分布趨勢：
#插入300708個key，后端節點為3個redis ? ? ? ? ? ? |
相同算法下，后續的數據都可以正常提取查找，但是原來已經在 Redis 的數據信息，部分找不到。具體數據如下：
算法規則 | 總keys數 | 未找到的keys | 找到的keys | 找到keys的比例 | 備注 |
distribution: ketama | 300708 | 147757 | 152951 | 51.86% | 缺省默認的算法 |
distribution: random | 300708 | 250731 | 49977 | 16.62% | ? |
distribution: modula | 300708 | 250408 | 50300 | 16.72% | ? |
distribution: ketama | 300708 | 147757 | 152951 | 50.86% | 缺省默認的算法 |
從上面可以看出，增加后端 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/
轉載于:https://blog.51cto.com/ultrasql/1657767
總結
以上是生活随笔為你收集整理的Redis 存储分片之代理服务Twemproxy 测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于64位Linux编译hadoop2
- 下一篇： org.tinygroup.databa