一、背景
2023年03月08日，在某地域進行了線上壓測，發現接口RT頻繁超時，性能下降嚴重，P50 400ms+，P90 1200ms+，P99 2000ms+。
細致排查發現其中重要的原因是，訪問緩存rt竟然飆到了1.2s左右。
作為高性能愛好者，榨干CPU的每一分價值是我們的宗旨，士可忍孰不可忍，怎么能光空轉，不干活呢？那就仔細分析下問題。
二、為啥redis訪問延時如此高？
我們簡化下Redis訪問流程如下：
可能性1：服務端問題？
我們Redis使用的
redis_amber_master_4xlarge_multithread 16C32G+480G SSD 規格，最大QPS參考值24w，最大連接數3w，配置還是非常豪華的。
如下，QPS以及Load在峰值請求階段，都仍然處于低位。
可能性2：物理網絡問題？
如下，請求遠遠沒有達到機器帶寬，不是瓶頸，另外單獨看了網卡重傳率等指標也都正常。
可能性3：客戶端問題？
那么很大概率就是客戶端自身問題了。我們把客戶端詳細放大如下：
①JVM FGC STW？
根據當時ARMS監控結果如下，雖然YGC次數與耗時有所上升，但沒有發生FGC：
②JedisPool問題？
把內存Dump出來，分析JedisConnectionFactory幾個相關重要指標，發現問題有如下2個：
- maxBorrowWAItTimeMills過大：即最大等待時間過久。在等待從連接池中獲取連接，最大等待了1200ms。很大概率是因為block在連接池獲取，導致請求處理緩慢。
- Redis連接創建銷毀次數過多：createdCount 11555次；destroyedCount：11553次。說明max-idle參數設置不合理（on return的時候檢查idle是否大于maxIdle，如果大于則直接銷毀該連接）。每個對象的創建就是一次TCP連接的創建，開銷較大。導致脈沖式請求過來時引發頻繁創建/銷毀，也會影響整體性能。
順便說一句：maxBorrowWaitTimeMills，createdCount，destroyedCount 幾個metrics信息是JedisPool對象持久維護的全局變量信息，只要JVM不重啟，這個信息就會一直存在。這也就是為啥不需要在壓測峰值時獲取內存dump，而是事后dump也可以。
此外，如果細致探索JedisPool參數工作機制，就需要了解Apache的ObjectPool2的機制。剛好筆者在之前研究過ObjectPool，后續會出單獨文章闡述&對比ObjectPool，ObjectPool2，JedisPool以及經常踩坑的DruidPool的實現原理與差異。
至此，定位問題是JedisPool行為異常導致。
三、如何解決問題？
線上JedisPool實際參數
部分參數是由 redis.clients.jedis.JedisPoolConfig 繼承而來
spring.redis.jedis.pool.max-active=100
spring.redis.jedis.pool.max-idle=16
spring.redis.jedis.pool.time-between-eviction-runs-millis=30000
spring.redis.jedis.pool.min-idle=0
spring.redis.jedis.pool.test-while-idle=true
spring.redis.jedis.pool.num-tests-per-eviction-run=-1
spring.redis.jedis.pool.min-evictable-idle-time-millis=60000
參數行為解析
- max-active：連接池的最大數量為100， 包括 idle + active. 注意， 這里spring.redis.jedis.pool.max-active被映射為了ObjectPool的maxTotal參數上。
- 連接池的最大空閑數量為16，即如果return時，idleObject>=16，則該對象直接被銷毀。
- 啟動后臺線程，每30s執行一次，定時心跳?；钆c檢測。
- 連接池最小空閑的連接數量為0。即corePoolSize為0，不會長期maintain一個固定的容量。
脈沖式請求引發的問題
我們把問題簡化為如下序列，即可發現問題所在。在T2~T3內，84個對象創建，84個對象銷毀，造成了極大的損耗。
期望的行為模式
由于線上環境，Redis服務器配置較高，為了能充分壓榨性能，同時應對容器場景下典型的突發峰值，因此如下行為：
- 連接池的最大數量=連接池的最小數量=連接池的穩定數量，即不要臨時去創建連接，防止等待過久。
- 需要定時心跳?；钆c檢測，及時刪除掉超時/無效的連接。
- 不要因為idle時間過久而重建連接（只因為連接失效而重建）。防止無意義的大規模連接重建。
spring.redis.jedis.pool.max-active=500 // 線上穩定保有4臺，4*500=2000，仍然遠小于Redis規格支持的3w
spring.redis.jedis.pool.max-idle=50
spring.redis.jedis.pool.time-between-eviction-runs-millis=30000 // 定時心跳保活與檢測
spring.redis.jedis.pool.min-idle=500 // 連接池的穩定數量
spring.redis.jedis.pool.test-while-idle=true //定時心跳?；钆c檢測
spring.redis.jedis.pool.num-tests-per-eviction-run=-1 // 每次?；顧z測， 都需要把500個連接都檢測一遍. 如果設置為-2， 則每次檢測1/2比例的的連接.
spring.redis.jedis.pool.min-evictable-idle-time-millis=-1 // 不要因為idleTime大于某個閾值從而把連接給刪除掉. 這樣可以防止無意義的大規模連接重建。
四、效果驗證
終于在20230413重新迎來了一波壓測，流量模型與上次相同。結果如下：
- maxBorrowWaitTimeMills 下降比例接近 80%
- createdCount 也從之前的 11555次 下降到了 500次(即池子初始化的size)
- 業務側整體性能也大幅提升，P50與P90均下降了將近60%，P99更是夸張地下降了70%。簡直是amazing，完結撒花！~
作者丨寒亭
來源丨公眾號：阿里開發者（ID：ali_tech）
