淺談Redis阻塞的9種情況

2023-03-25 06:03:32

命令阻塞

使用不當的命令造成使用者端阻塞：

這些命令時間複雜度是O(n)，有時候也會全表掃描，隨著n的增大耗時也會越大從而導致使用者端阻塞。

大家都知道 Redis 在進行 RDB 快照的時候，會呼叫系統函數 fork() ，建立一個子執行緒來完成臨時檔案的寫入，而觸發條件正是組態檔中的 save 設定。

當達到我們的設定時，就會觸發 bgsave 命令建立快照，這種方式是不會阻塞主執行緒的，而手動執行 save 命令會在主執行緒中執行，阻塞主執行緒。

當 Redis 直接記錄 AOF 紀錄檔時，如果有大量的寫操作，並且設定為同步持久化

appendfsync always

即每次發生資料變更會被立即記錄到磁碟，因為寫磁碟比較耗時，效能較差，所以有時會阻塞主執行緒。

fork 出一條子執行緒來將檔案重寫，在執行 BGREWRITEAOF 命令時，Redis 伺服器會維護一個 AOF 重寫緩衝區，該緩衝區會在子執行緒建立新 AOF 檔案期間，記錄伺服器執行的所有寫命令。
當子執行緒完成建立新 AOF 檔案的工作之後，伺服器會將重寫緩衝區中的所有內容追加到新 AOF 檔案的末尾，使得新的 AOF 檔案儲存的資料庫狀態與現有的資料庫狀態一致。
最後，伺服器用新的 AOF 檔案替換舊的 AOF 檔案，以此來完成 AOF 檔案重寫操作。

阻塞就是出現在第2步的過程中，將緩衝區中新資料寫到新檔案的過程中會產生阻塞。

AOF 的紀錄檔記錄不像關係型資料庫那樣在執行命令之前記錄紀錄檔（方便故障恢復），而是採用先執行命令後記錄紀錄檔的方式。

原因就是 AOF 記錄紀錄檔是不會對命令進行語法檢查的，這樣就能減少額外的檢查開銷，不會對當前命令的執行產生阻塞，但可能會給下一個操作帶來阻塞風險。

這是因為 AOF 紀錄檔也是在主執行緒中執行的，如果在把紀錄檔檔案寫入磁碟時，磁碟寫壓力大，就會導致寫盤很慢，進而導致後續的操作也無法執行了。

大 key 並不是指 key 的值很大，而是 key 對應的 value 很大。

大 key 造成的阻塞問題如下：

使用者端超時阻塞：由於 Redis 執行命令是單執行緒處理，然後在操作大 key 時會比較耗時，那麼就會阻塞 Redis，從使用者端這一視角看，就是很久很久都沒有響應。
引發網路阻塞：每次獲取大 key 產生的網路流量較大，如果一個 key 的大小是 1 MB，每秒存取量為 1000，那麼每秒會產生 1000MB 的流量，這對於普通千兆網路卡的伺服器來說是災難性的。
阻塞工作執行緒：如果使用 del 刪除大 key 時，會阻塞工作執行緒，這樣就沒辦法處理後續的命令。

當我們在使用 Redis 自帶的 --bigkeys 引數查詢大 key 時，最好選擇在從節點上執行該命令，因為主節點上執行時，會阻塞主節點。

我們還可以使用 SCAN 命令來查詢大 key；
通過分析 RDB 檔案來找出 big key，這種方案的前提是 Redis 採用的是 RDB 持久化。網上有現成的工具：
- redis-rdb-tools：Python 語言寫的用來分析 Redis 的 RDB 快照檔案用的工具
- rdb_bigkeys：Go 語言寫的用來分析 Redis 的 RDB 快照檔案用的工具，效能更好。