Redis 效能優化建議

jedispoolconfig jedispoolconfig =
newjedispoolconfig()
; jedispoolconfig.
setmaxtotal(5
); jedispoolconfig.
setmaxidle(2
); jedispoolconfig.
settestonborrow
(true);
jedispool jedispool =
newjedispool
(jedispoolconfig,
"192.168.0.60"
,6379
,3000
, null)
;jedis jedis = null;
trycatch
(exception e)
error: "
+ e.
getmessage()
, key, e);}
finally

連線池引數含義：

序號引數名

含義預設值

使用建議

1maxtotal

資源池中大連線數

8設定建議見下面

2maxidle

資源池允許最大空閒的連線數

8設定建議見下面

3minidle

資源池確保少空閒的連線數

0設定建議見下面

4blockwhenexhausted

當資源池用盡後，呼叫者是否要等待。

只有當為true時，下面的maxwaitmillis才會生效

true

建議使用預設值

5maxwaitmillis

當資源池連線用盡後，呼叫者的大等待時間(單位為毫秒)

-1：表示永不超時

不建議使用預設值

6testonborrow

向資源池借用連線時是否做連線有效性檢測(ping)，無效連線會被移除

false

業務量很大時候建議設定為false(多一次ping的開銷)。

7testonreturn

向資源池歸還連線時是否做連線有效性檢測(ping)，無效連線會被移除

false

業務量很大時候建議設定為false(多一次 ping的開銷)。

8jmxenabled

是否開啟jmx監控，可用於監控

true

建議開啟，但應用本身也要開啟

優化建議：

1）maxtotal

最大連線數，早期的版本叫 maxactive 實際上這個是乙個很難回答的問題，考慮的因素比較多：

以乙個例子說明，假設:

那麼理論上需要的資源池大小是 50000 / 1000 = 50個。但事實上這是個理論值，還要考慮到要比理論值預留一些資源，通常來講maxtotal 可以比理論值大一些。但這個值不是越大越好，一方面連線太多占用客戶端和服務端資源，另一方面對於 redis 這種高 qps 的伺服器，乙個大命令的阻塞即使設定再大資源池仍然會無濟於事。

2）maxidle 和 minidle

maxidle 實際上才是業務需要的大連線數，maxtotal是為了給出餘量，所以maxidle不要設定過小，否則會有new jedis(新連線)開銷。

連線池的最佳效能是 maxtotal = maxidle，這樣就避免連線池伸縮帶來的效能干擾。但是如果併發量不大或者 maxtotal 設定過高，會導致不必要的連線資源浪費。一般推薦 maxidle 可以設定為按上面的業務期望 qps 計算出來的理論連線數，maxtotal 可以再放大一倍。

minidle（小空閒連線數），與其說是小空閒連線數，不如說是"至少需要保持的空閒連線數"，在使用連線的過程中，如果連線數超過了minidle，那麼繼續建立連線，如果超過了 maxidle，當超過的連線執行完業務後會慢慢被移出連線池釋放掉。

3）連線池預熱

如果系統啟動完馬上就會有很多的請求過來，那麼可以給 redis 連線池做預熱，比如快速的建立一些redis連線，執行簡單命令，類似ping()，快速的將連線池裡的空閒連線提公升到 minidle 的數量。

示例**：

list
minidlejedislist =
newarraylist
(jedispoolconfig.
getminidle()
);for(
int i =
0; i < jedispoolconfig.
getminidle()
; i++
)catch
(exception e)
finally
}// 統一將預熱的連線還回連線池 
for(
int i =
0; i < jedispoolconfig.
getminidle()
; i++
)catch
(exception e)
finally
}

總之，要根據實際系統的qps和呼叫redis客戶端的規模整體評估每個節點所使用的連線池大小。

【推薦】o(n)命令關注n的數量。

例如 hgetall、lrange、smembers、zrange、sinter 等並非不能使用，但是需要明確n的值。有遍歷的需求可以使用 hscan、sscan、zscan代替。

【推薦】禁用命令。

禁止線上使用 keys、flushall、flushdb 等，通過redis的rename機制禁掉命令，或者使用scan的方式漸進式處理。

【推薦】合理使用select。

redis的多資料庫較弱，使用數字進行區分，很多客戶端支援較差，同時多業務用多資料庫實際還是單執行緒處理，會有干擾。

【推薦】使用批量操作提高效率。

原生命令：例如mget、mset。

非原生命令：可以使用pipeline提高效率。

但要注意控制一次批量操作的元素個數(例如500以內，實際也和元素位元組數有關)。注意兩者不同：

原生是原子操作，pipeline是非原子操作。

pipeline 可以打包不同的命令，原生做不到

pipeline 需要客戶端和服務端同時支援。

【推薦】redis事務功能較弱，不建議過多使用，可以用lua替代。

【推薦】選擇合適的刪除策略。

redis 對於過期鍵有三種清除策略：

注意，當 redis 執行在主從模式時，只有主結點才會執行被動和主動這兩種過期刪除策略，然後把刪除操作」del key」同步到從結點。

第三種策略的情況如下：當前已用記憶體超過 maxmemory 限定時，會觸發主動清理策略。所以，我們需要根據自身業務型別，選好 maxmemory-policy(大記憶體淘汰策略)，設定好過期時間。如果不設定大記憶體，當 redis 記憶體超出物理記憶體限制時，記憶體的資料會開始和磁碟產生頻繁的交換 (swap)，會讓 redis 的效能急劇下降。

預設策略是 volatile-lru，即超過大記憶體後，在過期鍵中使用 lru 演算法進行 key 的剔除，保證不過期資料不被刪除，但是可能會出現oom 問題。

【推薦】高併發下建議客戶端新增熔斷功能(例如netflix hystrix)

【推薦】設定合理的密碼，如有必要可以使用ssl加密訪問

Redis 效能優化建議

Redis 效能優化建議

優化建議儲存效能優化。

React Native 效能優化建議

Redis 效能優化建議

Redis 效能優化建議

優化建議 儲存效能優化。

React Native 效能優化建議

相關推薦

優化建議儲存效能優化。