记twemproxy的一次性能测试
twemproxy的性能应该很好，毕竟是twitter在使用的，稳定性应该很高。
然而测试组的同学对其二倍扩容以后，基本没提升QPS，甚至QPS还降低了
我和我的小伙伴们一直以为是客户端或者服务端代码的问题，各种抓包，LOG分析，查不出原因。写了C,JAVA等多个客户端版本。
后面发现原来是测试组的布线坑爹了。
关于之前测试环境redis集群极限qps提升不上去的问题，认定是由于之前4台测试环境部署的宿主机，走的交换机，交换机网络达到瓶颈导致的。
之前性能无法提升的集群架构如下所示：
4台proxy4台redis8台jetty都是独立的虚拟机
一共4台宿主机，每个宿主机都走一个交换机和其他的机器相连接。看似每台proxy-redis之间互不影响，其实不然，在4台中2台的proxy上取某个key，居然要11秒，另外两台只需要0秒，通过iperf对这两台proxy和该key所在redis之间的网络分别做测试，发现TCP只能跑到20多MB（关闭了所有客户端以后能跑到110MB），导致了测试数据严重失真。C和JAVA客户端扩容后均不能提高QPS。
经过思考以后，决定如下部署：
同样是4proxy4redis8jetty
Proxy和redis之间走内环，相互都能到理论的128M/S，8台jetty能提供4128M+2128M数据流的压力，足够测试使用
这样的测试环境摆脱了网络的影响，纯粹考虑proxy的计算量如何
使用java线上的版本进行测试3K大小的key，2proxy2redis的情况下进行3分钟的数据采集，平均结果是30536.473 QPS,4proxy4redis后达到61343.87323的QPS,提升了100%
初步认定，达到了扩容后二倍提升性能的需求
另外，4proxy4redis无法提升时网络未跑满，而proxy的CPU跑满了，使用4proxy2redis进行测试，平均53814.31的QPS，提升了76%，观察网络，发现proxy的网络达到瓶颈，而CPU只有80%左右
通过确认线上环境的网络拓扑结构，初步结论是线上环境进行二倍扩容，QPS提升和节点数增加成线性关系。
DBA可以放心扩容
另外附上2redis-2proxy的不同大小KEY下的极限QPS情况:
横轴是KB，纵轴是QPS值。
因此很容易就可以算出来多redis-proxy时QPS上限值：
如4redis4proxy的值，3K时是6W左右,15K时是3W2左右
而4redis8proxy的值，3K时是6W1.76 = 10.56W,15K时是3W21.76 = 5.632W
4redis6proxy的值，3K时就应该是8.28W,15K时是4.416W
最后附上C的redis集群极限测试代码
-
2015-06-11
业务线上出错，返回给用户的结果不正确。
使用了ZINTERSTORE这个接口对多个集合做交并集返回预期外的空集。如下图：
这是因为twemproxy只是把指令转发给redis而已，而多个集合被哈希算法分片在不同的redis节点上，所以转发这个redis并没有这几个集合，会直接返回空集。
这并不是BUG，redis3.0也存在这个特性，当多个集合做交并集操作时，需要使用hash_tag特性。