Redis 慢查詢,Pipline和發布訂閱

2021-09-25 02:36:02 字數 2356 閱讀 8438

redis 提供了慢查詢日誌記錄,把命令執行時間超過slowlog-log-slower-than的都記錄在 reids 內部的乙個列表(list)中,該列表的長度最大為slowlog-max-len。需要注意的是,慢查詢記錄的只是命令的執行時間,不包括網路傳輸和排隊時間。

關於 redis 慢查詢的配置有兩個,分別是slowlog-log-slower-thanslowlog-max-len

slowlog get [n] 

# 通過引數 n 指定檢視條數

127.0.0.1:6379> slowlog get

1) 1)

(integer) 456

2)(integer) 1531632044

3)(integer) 3

4) 1)

"get"

2)"m" 5)

"127.0.0.1:50106"

6)"" 2) 1)

(integer) 455

2)(integer) 1531632037

3)(integer) 14

4) 1)

"keys"

2)"*" 5)

"127.0.0.1:50106"

6)""# 慢查詢結果說明:

# 1) 慢查詢記錄 id;

# 2) 發起命令的時間戳;

# 3) 命令耗時,單位為微秒;

# 4) 該條記錄的命令及引數;

# 5) 客戶端網路套接字(ip: port);

# 6) 「」

獲取當前慢查詢日誌記錄數

slowlog len
127.0.0.1:6379> slowlog len

(integer) 458

慢查詢日誌重置

slowlog reset
實際上是對慢查詢列表做清理操作:

127.0.0.1:6379> slowlog len

(integer) 461

127.0.0.1:6379> slowlog reset

ok127.0.0.1:6379> slowlog len

(integer) 1

注:

slowlog-max-len不要設定過小,通常設定1000左右

slowlog-log-slower-than不要設定過大,預設10ms,通常設定1ms 理解命令生命週期

可以通過slowlog get等命令定期將慢查詢命令持久化到其他資料來源,這樣就可以查到很多歷史的慢查詢操作命令

在生產環境中,不管slowlog-max-len設定多大,當慢查詢命令逐步增多時,最開始的慢查詢命令會被丟掉

當需要查詢歷史資料時,這些慢查詢命令都是非常關鍵的 可以使用開源軟體來實現這些功能,對於分析解決redis問題是非常有幫助的

pipeline就是把一批命令進行打包,然後傳輸給server端進行批量計算,然後按順序將執行結果返回給client端,從而節省網路傳輸時間的開銷。

如:

package main

}}

注:

Redis 慢查詢分析

慢查詢,大家可能已經接觸到了mysql的慢查詢。我們配置乙個時間,如果查詢時間超過了我們設定的時間,我們就認為這是乙個慢查詢.慢查詢引數配置 redis 通過 slowlog log slower than 和 slowlog max len 分別配置慢查詢的閾值,以及慢查詢記錄的日誌長度。slow...

Redis 慢查詢分析

慢查詢,顧名思義就是比較慢的查詢,但是究竟是 慢呢?首先,我們了解一下redis命令執行的整個過程 傳送命令 命令排隊 命令執行 返回結果 在慢查詢的定義中,統計比較慢的時間段指的是命令執行這個步驟。沒有慢查詢,並不表示客戶端沒有超時問題,有可能網路傳輸有延遲,也有可能排隊的命令比較多。因為redi...

實戰 Redis 慢查詢

redis 慢查詢作用和 mysql 慢查詢作用類似,都是為我們查詢出不合理的執行命令,然後讓開發人員和運維人員一起來規避這些耗時的命令,從而讓伺服器更加高效和健康的執行。對於單執行緒的 redis 來說,不合理的使用更是致命的,因此掌握 redis 慢查詢技能對我們來說非常的關鍵。我們先來看它們的...