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是單線程的原因。