Redis Qps低下的原因以及解決方案
問題緣由
今天在一本Java EE的書上看到了一個測試Qps的案例，使用Jedis測試的，裏面的Qps達到了23K+，於是我很好奇我的Qps是否能比他的更大，但是當結果出來之後，我就傻眼了。
Jedis測試Qps僅僅只有26！mysql的插入速度都沒有這麼慢！
於是我打開我的服務器，看了一眼內存使用狀況：
然後又用Redis自帶的測試工具測試了Redis的性能：
測得的Qps有46K+ ！看來應該不是Redis的問題，這可能是網絡問題導致的！
本地虛擬機測試
如果是網絡問題的話，那當然需要現在本地測試啦。之後在本地的虛擬機裏也裝了一個redis，並且進行測試，結果比連接服務器上的Redis的Qps要高很多（2K+），但是遠遠達不到23K+的程度。
然後我將虛擬機的內存由1G升到2G，cpu還是保持一個核心。（雖然知道不是這些原因，但是就像試試，萬一真有什麼關係呢……）
結果還是2K+，不過這次接近3K+ …… 看來性能問題和cpu和內存都沒有關係，我通過top指令發現cpu的負載最高只有25%
於是我決定把密碼給關閉，看看是不是給redis設置了密碼造成了如此之大的影響，下面是測試結果：
看來和密碼沒有關係……
將服務和redis放在同一個機器上進行測試
直接在虛擬機裏進行虛擬機的Redis測試，結果比從宿主機連接到虛擬機的Redis測試快了3倍多，果然還是和網絡問題有些關係的，但是還遠遠不能達到書上的效果。於是我決定經虛擬機的CPU從1個提高到4個。再此之前先用Redis自帶的工具測試下虛擬機Redis的性能指標：
虛擬機內Redis的Qps爲63K+，但是用Jedis測試卻只有8K+
CPU調到4核後的測試結果：
Jedis測試的Qps達到了15K+！比上一次高了快一倍！看來和CPU有些關聯，但是同時又和網絡有關聯。於是現在開始了找文檔之旅……
突然想起來，如果是網絡問題，會不會是Jedis單線程堵塞了命令，因爲舊的命令還未執行完，因此無法執行新的命令，於是我就是用了多線程連接遠程服務器：
確實正常多了，但是這個真的能算是正常的Qps測試嗎？
既然已經鎖定是網絡問題了，那當然要ping一下查看延遲，結果一個來回是25ms左右，用1000一除…… 果然是網絡問題導致的低Qps。1秒內，我的筆記本與服務器單線程數據傳輸週期的結果28和我測試Jedis的28很像呢……
要解決Jedis低Qps的問題（指28的qps），需要想辦法降低網絡時延。
我的虛擬機時延以及虛擬機本地的時延：
之前虛擬機內的Jedis測試虛擬機中的Redis達到了15K+，看來性能瓶頸也在時延上呢…… 這次根據ping的time手動計算得到的是12K+。
解決方案
- 將項目放置在它所使用的Redis的服務器，時延極低（<1ms）。
- 降低存放項目的服務器與服務器之間的時延，比如放在兩個比較接近的服務器上，時延一般也<1ms。
- 項目中使用多線程對Redis進行操作，而不是“單線程”，單線程指【static Jedis a，然後方法上還加了同步】這樣的寫法。
- 使用redis的“流水線"(pipelinwd)功能，如果是比較緊湊的業務，可以手動編寫一個讓流水線每秒自動提交一次的工具類來提高Jedis的Qps。
參考文章（雖然最後也沒在我的這個問題中用到…… 但是肯定在別的問題中是有用的）
https://www.cnblogs.com/mushroom/p/4738170.html
https://www.cnblogs.com/williamjie/p/9660427.html