1、 测试背景：由于业务需求，开发决定部署一个redis高可用方案codis，使用codis3.2版本。
2、 代码：非常简单的redis读写方法，读和写分开测。
3、基本架构：一台应用服务器（12核48G），单实例proxy（48核198G），三实例zk集群（48核198G），三组codis-server，每组各一个codis-server，具体配置信息如下。
4、开始压测，结果发现，TPS最高在1800左右，100并发时平均响应时间为53ms，200并发时平均响应时间为111ms，TPS基本不变，应用服务器CPU使用率在25%左右，codis和redis服务器压力非常小，典型的存在性能瓶颈的现象，开始定位瓶颈。
5、查看线程信息，发现有很多log4j的锁，基本定位问题，瓶颈是log4j引起的。也可以确定，log4j使用的是1.x版本，因为这个版本在多线程写日志时，存在同步锁，而Log4j 2使用了新一代的基于LMAX Disruptor的无锁异步日志系统。在多线程的程序中，异步日志系统吞吐量比Log4j 1.x高10倍，而时间延迟更低。这也是我们现在都用log4j2的原因。还只是猜测，实验一下吧。
6、更改log4j日志级别为OFF，就是不打印任何日志，然后重启。测试结果如下，上周五晚上测试结果读的TPS能到18000+，写能到20000+，瓶颈在应用服务器上，今天是下午进行的测试，读的TPS大概就13000，估计可能是网络原因，确实存在晚上比白天网络好很多的情况。
总结：本次测试基本上能了解codis的整体性能，20000的TPS是完全能满足需求的，给开发的建议也就是升级log4j到log4j2。
PS：redis使用单线程，只能使用单核CPU，实际测试中，redis的CPU使用率非常低，单核只用了20%多，所以说redis的性能瓶颈不在CPU上，或许这也是redis是单线程的原因。