一、訪問卡頓
目前通過skywalking發(fā)現(xiàn)，redis出現(xiàn)大量的Lettuce/HGETALL訪問，導(dǎo)致系統(tǒng)訪問奇慢。
image.png
二、分析
查詢redis的cpu水位壓力，在4%，相當(dāng)于沒有壓力。
懷疑沒有流量進(jìn)入，是不是客戶端的請求都被攔著了？
看下服務(wù)中開放的redis的連接池情況：
lettuce:
cluster:
refresh:
adaptive: true
period: 20
pool:
# 連接池中的最小空閑連接
min-idle: 5
# 連接池中的最大空閑連接
max-idle: 10
# 連接池的最大數(shù)據(jù)庫連接數(shù)
max-active: 20
# #連接池最大阻塞等待時間（使用負(fù)值表示沒有限制）
max-wait: 2000ms
testOnCreate: true
testOnBorrow: true
testOnReturn: true
testWhileIdle: true
最大連接數(shù)，只允許20個鏈接，如果超過這個請求，需要等待。
看了下目前redis鏈接請求為154個
image.png
三、解決問題
這時就在想，是不是服務(wù)開放出去的redis鏈接太少了，導(dǎo)致等待。試著調(diào)大一下連接數(shù) max-active。為了不超過redis的最大承載能力，我們查看了redis的最大連接數(shù)是60000個，這是后可以大膽的去擴(kuò)大了。
lettuce:
cluster:
refresh:
adaptive: true
period: 20
pool:
# 連接池中的最小空閑連接
min-idle: 50
# 連接池中的最大空閑連接
max-idle: 50
# 連接池的最大數(shù)據(jù)庫連接數(shù)
max-active: 500
# #連接池最大阻塞等待時間（使用負(fù)值表示沒有限制）
max-wait: 2000ms
testOnCreate: true
testOnBorrow: true
testOnReturn: true
testWhileIdle: true
于是我們把連接數(shù)擴(kuò)大到了500，完美解決問題，系統(tǒng)快的飛起，完美解決。
