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