1 redis 单节点基准性能

redis本身自带了一个性能测试工具 redis-benchmark
该工具可以模拟多客户端同时向某个redis节点发送大量的请求，以测试该redis节点的性能。
典型的使用方式为：

$ redis-benchmark -n 1000 -t set,get -P 16 -q -c 1 -d  10
SET: 403063.28 requests per second
GET: 508388.41 requests per second

其中-n指定了请求总数， -P指定了pipeline模式的请求数， c指定了客户端个数 t指定了请求类型,-d指定了请求中value以字节为单位的大小(可以使用-h 获取该工具的帮助说明)
有了该工具后，我们就可以测试出单个redis节点的实际性能。
影响redis节点性能的因素包括：

网络的吞吐和延迟千兆、万兆网络
cpu 比如是否打开cpu节能
磁盘如果是虚拟化的磁盘可能会影响性能
redis节点的连接数 30000个连接的redis节点性能只有100个连接的一半

一些更深入的性能因素包括：

网卡的中断配置使得cpu的多个core都可以响应网络中断提高系统的网络性能
redis 内存分配器

根据官方的说明，一个redis节点能够提供的ops峰值在10w左右。和具体的请求、硬件配置、网络有关。在我自己的测试环境中，未进行任何特殊优化的redis节点的ops在1w左右。
值得注意的是redis节点是单线程的，并不能充分利用多核cpu的性能，只有当超过redis性能时，我们可以考虑一台主机上启动多个实例。

2 codis 集群性能分析

codis集群中，通过代理节点proxy去访问后端的redis节点。proxy根据zookeeper中存储全局数据的slot分区信息，选择该key对应的redis节点，redis读写完成后数据又再次回到proxy，返回给客户端。
proxy ==> redis ==> proxy
根据codis的官方解释，理论上proxy只会降低redis-server一半的性能。另外，proxy会连接所有的redis server以读写所有slot的数据。
在开始分析集群性能之前，我们可以对单台proxy/redis-server 进行性能测试,这样集群的整体性能我们已经可以估算出来。我们需要确认整个系统中，每分钟/秒钟向codis集群中写入的数据量，是否理论上能够满足。理论值都无法满足时，我们就需要从硬件升级、横向扩容上考虑codis集群的升级。
为了进一步分析codis集群的性能问题，我们可以按照下述方法去分析集群：

检查proxy、redis server的连接数。注意系统配置中ulimit -n的值是否设置的太小。
proxy默认是WARN日志，打开INFO日志，分析日志中是否有异常。
打开方法：./codis-admin --proxy=10.1.236.65:11080 --log-level=INFO
使用上面提到的redis-benchmark工具分别去测试proxy 、codis-server的性能。
如果直接访问redis server性能正常，proxy的性能比redis-server下降了太多，比如只有十分之一，那么proxy到redis-server之间应该是出现了异常。很大的可能是网络的异常，由于通过proxy测试时，会向多台redis-server之间发起读写请求，那么可以测试从该proxy节点向其他的redis-server执行redis-benchmark性能是否有异常，以进一步分析问题。
注意，如果是线上集群，redis-benchmark不要指定太大的数据量,以避免写入过多的垃圾数据。
redis 性能分析可以通过redis的slowlog 来分析是否有响应缓慢的请求，通过命令CONFIG GET slowlog-log-slower-than 来配置记录的slowlog的阈值，注意单位是毫秒，默认为0。

redis 127.0.0.1:6379> slowlog get 2
1) 1) (integer) 14
   2) (integer) 1309448221
   3) (integer) 15
   4) 1) "ping"
2) 1) (integer) 13
   2) (integer) 1309448128
   3) (integer) 30
   4) 1) "slowlog"
      2) "get"
      3) "100"

参考：
redis benchmark https://redis.io/topics/benchmarks
redis slowlog https://redis.io/topics/latency