twemproxy for redis使用說明及簡單分析

redis的資料量在記憶體高過50G時系統出現了明顯的瓶頸。為瞭解決這個問題，筆者找了些相關的資料，發現了這個開源軟體。功能很強大，包含了last.fm的ketama的一致性hash演算法，對於筆者目前的需求，該軟體已經能夠完全滿足。

軟體的原始碼已經在git上面開源：https://github.com/twitter/twemproxy

下載和安裝的過程就不再贅述，在README中有詳細的敘述。這裡主要說一說如何配置一個自己的叢集。

安裝完成之後，修改設定檔。

alpha:                                                                                                                                         listen: 127.0.0.1:22121  hash: fnv1a_64  distribution: ketama  auto_eject_hosts: true  redis: true  server_retry_timeout: 2000  server_failure_limit: 1  servers:   - 127.0.0.1:8604:1   - 127.0.0.1:8605:1   - 127.0.0.1:8606:1   - 127.0.0.1:8607:1

按照設定檔中的連接埠啟動兩台redis伺服器，權重均配置為1，不用設定資料庫的index。

啟動完成redis之後，啟動代理服務。

$ nutcracker -d

此時，nutcracker就已經啟動了，下面可以使用redis的用戶端做簡單的測試。

$ ./redis-cli -p 22121 set abc abc

$ ./redis-cli -p 22121 get abc

簡單測試之後結果正常。

為了簡單測試proxy的效能，使用指令碼執行批量寫入的操作：

#!/usr/bin/perl                                                                                                                              # Program:#     # History:# Author: luyao(yaolu1103@gmail.com)# Date:  2013/02/22 17:09:30use strict;my @port = (8604, 8605, 8606, 8607);my $pre = shift;for (my $i = 0; $i< 1000;$i++) {  my $num = rand;  `./redis-cli -p 22121 set $pre$i $i`;}

使用shell命令調用：

$for i in a b c d e f g h i j k l m n o p q r s t u v w x y z;do sh -c "time perl test.pl $i&";done

結果如下：

real    0m3.315suser    0m0.457ssys     0m1.473sreal    0m3.391suser    0m0.458ssys     0m1.512sreal    0m3.433suser    0m0.459ssys     0m1.455sreal    0m3.475suser    0m0.449ssys     0m1.465sreal    0m3.442suser    0m0.472ssys     0m1.465sreal    0m3.483suser    0m0.471ssys     0m1.421sreal    0m3.487suser    0m0.467ssys     0m1.459sreal    0m3.440suser    0m0.480ssys     0m1.425sreal    0m3.498suser    0m0.452ssys     0m1.428sreal    0m3.403suser    0m0.445ssys     0m1.411sreal    0m3.505suser    0m0.479ssys     0m1.416sreal    0m3.495suser    0m0.461ssys     0m1.483sreal    0m3.424suser    0m0.465ssys     0m1.422sreal    0m3.477suser    0m0.496ssys     0m1.403sreal    0m3.521suser    0m0.454ssys     0m1.474sreal    0m3.494suser    0m0.491ssys     0m1.399sreal    0m3.550suser    0m0.446ssys     0m1.435sreal    0m3.539suser    0m0.445ssys     0m1.442sreal    0m3.527suser    0m0.501ssys     0m1.447sreal    0m3.477suser    0m0.468ssys     0m1.442sreal    0m3.569suser    0m0.449ssys     0m1.405sreal    0m3.512suser    0m0.462ssys     0m1.428sreal    0m3.539suser    0m0.472ssys     0m1.388sreal    0m3.584suser    0m0.483ssys     0m1.396sreal    0m3.529suser    0m0.468ssys     0m1.396sreal    0m3.554suser    0m0.459ssys     0m1.398s

根據上述資料，proxy在3.5s內寫入了1000*26條資料，7000+ QPS。考慮到所有的redis服務以及寫入服務均在同一台機器上部署，因此，真實能力應該大於該值。

最後，查看一下key的分布情況：

8604：db0:keys=7760,expires=0

8605：db0:keys=6010,expires=0

8606：db0:keys=6545,expires=0

8607：db0:keys=5685,expires=0

key的分布基本ok，考慮到key都比較簡單，而且可能相似"a-z+0-999"，因此，該分布表現仍可以接受。