Redis 存储分片之代理服务Twemproxy 测试
Redis 存儲分片之代理服務(wù)Twemproxy 測試
轉(zhuǎn)載自：http://blog.jpush.cn/redis-twemproxy-benchmark/
概述
實際業(yè)務(wù)場景中單點 Redis 容量、并發(fā)都是有限的，所以有 Redis Cluster 的需求。
但是官方的 Redis Cluster 一再跳票，還不可用。
只好先使用最簡單的方式：Proxy。有很多可選，但在大范圍生產(chǎn)使用的， Twitter 開源的 Twemproxy? 看起來是個理想的選擇 - https://github.com/twitter/twemproxy 。
我們期望的目標：
tag/alias 緩存集群（現(xiàn)在單點容量支持越來越不夠）
數(shù)據(jù)統(tǒng)計時高并發(fā)緩存
下面的文章內(nèi)容也是基于實際生產(chǎn)需要而進行的一系列測試.
?
測試環(huán)境說明
本次測試的機器都是虛擬機，對應(yīng)的母機配置為 Dell R710?? Intel(R) Xeon(R) CPU?????? E5606? @ 2.13GHz? 2CPU(單CPU 4核)? 32G內(nèi)存，上面安裝了4臺虛擬機，配置分別如下：
序號 | 機器IP | 配置 | 部署服務(wù) | redis服務(wù)數(shù)量 |
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) |
虛擬機系統(tǒng)： CentOS release 6.3 (Final)????
Redis版本：2.6.16
Twemproxy版本：nutcracker-0.2.4
部署示意圖
下面的測試都是根據(jù)上面的配置不同組合來進行測試得出對應(yīng)的結(jié)論。
測試工具：Redis Benchmark.
?
測試結(jié)論
功能
前端使用 Twemproxy 做代理，后端的 Redis 數(shù)據(jù)能基本上根據(jù) key 來進行比較均衡的分布。
后端一臺 Redis 掛掉后，Twemproxy 能夠自動摘除。恢復(fù)后，Twemproxy 能夠自動識別、恢復(fù)并重新加入到 Redis 組中重新使用。
Redis 掛掉后，后端數(shù)據(jù)是否丟失依據(jù) Redis 本身的策略配置，與 Twemproxy 基本無關(guān)。
如果要新增加一臺 Redis，Twemproxy 需要重啟才能生效；并且數(shù)據(jù)不會自動重新 Reblance，需要人工單獨寫腳本來實現(xiàn)。
如同時部署多個 Twemproxy，配置文件一致（測試配置為distribution：ketama,modula），則可以從任意一個讀取，都可以正確讀取 key對應(yīng)的值。
多臺 Twemproxy 配置一樣，客戶端分別連接多臺 Twemproxy可以在一定條件下提高性能。根據(jù) Server 數(shù)量，提高比例在 110-150%之間。
如原來已經(jīng)有 2 個節(jié)點 Redis，后續(xù)有增加 2 個 Redis，則數(shù)據(jù)分布計算與原來的 Redis 分布無關(guān)，現(xiàn)有數(shù)據(jù)如果需要分布均勻的話，需要人工單獨處理。
如果 Twemproxy 的后端節(jié)點數(shù)量發(fā)生變化，Twemproxy 相同算法的前提下，原來的數(shù)據(jù)必須重新處理分布，否則會存在找不到key值的情況。
性能
不管 Twemproxy 后端有幾臺 Redis，前端的單個 Twemproxy 的性能最大也只能和單臺 Redis 性能差不多。
?
Twemproxy介紹
Twemproxy 也叫 nutcraker。是 Twtter 開源的一個 Redis 和 Memcache 代理服務(wù)器，主要用于管理 Redis 和 Memcached 集群，減少與Cache 服務(wù)器直接連接的數(shù)量。
Twemproxy特性：
輕量級、快速
保持長連接
減少了直接與緩存服務(wù)器連接的連接數(shù)量
使用 pipelining 處理請求和響應(yīng)
支持代理到多臺服務(wù)器上
同時支持多個服務(wù)器池
自動分片數(shù)據(jù)到多個服務(wù)器上
實現(xiàn)完整的 memcached 的 ASCII 和再分配協(xié)議
通過 yaml 文件配置服務(wù)器池
支持多個哈希模式，包括一致性哈希和分布
能夠配置刪除故障節(jié)點
可以通過端口監(jiān)控狀態(tài)
支持 linux, *bsd,os x 和 solaris
Twemproxy安裝配置參考官網(wǎng)：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 方式啟動。
運行中如果需要查看運行狀態(tài)使用下面方式，結(jié)果為json格式，需要自己格式化。
1.web界面運行啟動服務(wù)的http://ip:22222查看，如本次測試查看url：http://192.168.2.68:22222/
2.使用nc命令查看 Twemproxy 狀態(tài)語句：
$nc?192.168.2.68?22222|python?-mjson.tool?
Twemproxy支持命令測試
源碼的scripts中包含一些腳本可以進行基本功能測試，如下：
?
scripts目錄腳本 ? ?
[root@test66 scripts]$ ls -tlh ? ? ? ? ? ? |
從執(zhí)行結(jié)果看，下面命令都可以使用(結(jié)合我們常用的命令)
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
如果生產(chǎn)環(huán)境中使用的話，建議先檢查是否有無法使用的命令后在決定使用。
?
Twemproxy 和單機 Redis 對比測試
測試方法：使用 Redis 自帶壓力測試工具 redis-benchmark 測試2-3次，取其中比較好的結(jié)果。
注：測試本機上面的 Redis 都是在其他客戶端上面執(zhí)行，避免由于不通過網(wǎng)絡(luò)導(dǎo)致測試不準確.另外每次運行結(jié)果都有不同差距。
執(zhí)行命令類似如下：
$/usr/local/bin/redis-benchmark?-h?192.168.2.68?-p?10000?-c?100?-qTwmemproxy 配置的后端 Redis 信息如下：
… ? ? ? ? ? ? |
從自帶的壓力測試工具看，基本上 Twemproxy 的性能和單臺 Redis 服務(wù)基本差不多。后端自帶 Redis 只是為數(shù)據(jù)更好的split(由于從實際統(tǒng)計信息看看，壓力測試實際上只訪問了后端的其中某一臺redis服務(wù)，故這個結(jié)果也屬于正常)
命令\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 數(shù)量測試對比
本測試主要驗證 Twemproxy 后端接入不同 Redis 數(shù)量后，測試的ops比較，結(jié)果只能作為參考意義。
設(shè)置測試方式，Twemproxy 的分布方式設(shè)置為 hash，測試對比如上圖。基本上和單臺redis性能差不多。實際看后端也只訪問一臺redis。
分布參數(shù)設(shè)置為random模式。可以比較均勻分布。
測試類似命令：
/usr/local/redis/bin/redis-benchmark?-h?192.168.2.65?-p?9999?-t?SET??-n?1000000?-c?100?-q目前環(huán)境： 2臺機器都搭建 Twemproxy Server，每臺端口為9999，19999，29999
目前6臺 Redis 分別測試的結(jié)果為:
(31438.63+32406.51+37087.86+26886.78+34291.20+32544.67)/6=32442.6083
可以近似看成是 Redis 的單臺性能。
測試方式：
1.后端 Redis 節(jié)點數(shù)量不變，不同 Twemproxy server 測試及多個同時運行測試結(jié)果如下：
twemproxy server運行數(shù)量(port) | 1(A server) | 1(B Server) | 2 | 4 | 6 |
測試結(jié)果(/s) | 30278.26 | 32867.71 | 35143.28 | 40176.777 | 52345.5152 |
從上面數(shù)據(jù)可以看出，單臺最多也只能達到單個 Redis 的性能；2個節(jié)點運行性能增加大概110%左右。4個 server 運行，性能大概增加了123%，6個 server 接入運行160%。
2.前端使用1個 Twemproxy server，后端 Redis 數(shù)量分別為2，3，4，5，6來進行壓力測試，看測試結(jié)果,測試數(shù)據(jù)如下：
redis節(jié)點數(shù) | 2 | 3 | 4 | 5 | 6 |
測試結(jié)果(/s) | 34882.1 | 34749.97 | 32296.61 | 32438.04 | 32867.71 |
從數(shù)據(jù)可以看出，后端節(jié)點數(shù)量與 Twemproxy 的性能基本無關(guān)，最大性能也就是單個 Redis 的性能。
?
Twemproxy功能測試
1.Twemproxy 正常訪問，后端 Redis 掛掉一臺，前端訪問是否正常;后端 Redis 掛掉的恢復(fù)，不重啟 Twemproxy，觀察恢復(fù)的數(shù)據(jù)是否有繼續(xù)增加
從測試結(jié)果看，基本正常，由于使用命令/usr/local/bin/redis-cli，無法看到錯誤信息，不能確認在中斷瞬間是否有報錯。
從各 Redis 的 keys 數(shù)量看，基本可以滿足.測試過程中 Redis 中斷不到1分鐘。從實際數(shù)據(jù)看只丟失了15個key(總key數(shù)量為26W)，可以認為Twemproxy 能夠自動摘掉故障的 Redis 及自動恢復(fù)。
#初始化redis，各redis中的keys為空 ? ? ? ? ? ? |
2.正常裝載一部分數(shù)據(jù)，計算后端各 Redis 的 key 分布情況是否均勻
#總共插入26W個key,通過twemproxy的端口操作 ? ? ? ? ? ? |
3. Twemproxy 默認使用(distribution: ketama)先使用后端3個節(jié)點裝載key數(shù)量：300708 ，然后后端節(jié)點增加到6個(distribution: ketama)，在裝載300708個 key 值，對比分布趨勢：
#插入300708個key，后端節(jié)點為3個redis ? ? ? ? ? ? |
相同算法下，后續(xù)的數(shù)據(jù)都可以正常提取查找，但是原來已經(jīng)在 Redis 的數(shù)據(jù)信息，部分找不到。具體數(shù)據(jù)如下：
算法規(guī)則 | 總keys數(shù) | 未找到的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 點有一定關(guān)系(剛好大概一半找不到。我們增加了1倍的節(jié)點)
?
數(shù)據(jù)一致性測試
測試方法，分別開3個 Twemproxy server(port)，分布格式為 ketama，ketama，random。從其中一個 ketama 分布的插入。然后分別從其他2個不同類型的 server 讀取，判斷讀取值是否正確。
裝載數(shù)據(jù)共300708記錄，然后使用 get 方式讀取，對應(yīng)的 key 還是從源文件讀取 key。可以看到，類型為 ketama 的2臺 server 都可以全部獲取到對應(yīng)的key值，而 random 有2/3獲取不到(總記錄300708，能獲取到key的記錄:100347).
?
Reference
在測試中參考的網(wǎng)絡(luò)部分資料，本文章中部分內(nèi)容也有引用，在此感謝！
官網(wǎng)：https://github.com/twitter/twemproxy
翻譯介紹： http://1.breakwang.sinaapp.com/?p=78
安裝測試：http://blog.mkfree.com/posts/515bce9d975a30cc561dc360#
Redis : http://redis.io/
轉(zhuǎn)載于:https://blog.51cto.com/ultrasql/1657767
總結(jié)
以上是生活随笔為你收集整理的Redis 存储分片之代理服务Twemproxy 测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于64位Linux编译hadoop2
- 下一篇： org.tinygroup.databa