美團二面：細數 Redis 阻塞的九種情況

作者：阿Q 2023-04-21 13:57:38

執行遷移時，兩端的 Redis 均會進入時長不等的阻塞狀態，對于小Key，該時間可以忽略不計，但如果一旦 Key 的內存使用過大，嚴重的時候會觸發集群內的故障轉移，造成不必要的切換。

哈嘍大家好，我是阿Q！

前兩天去美團面試的陳同學回來了，看他滿臉泄氣的樣子，準是沒拿到 Offer。

聽了他面試的經過，真替他感到惋惜。究其原因，是被一道面試題攔住了去路：看你簡歷上寫著精通 Redis，請你總結一下 Redis 中存在的阻塞問題吧。

正好阿Q這幾天正在研究 Redis，就順便在這兒給大家做個總結。

命令阻塞

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

這些命令時間復雜度是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 時，最好選擇在從節點上執行該命令，因為主節點上執行時，會阻塞主節點。

刪除操作的本質是要釋放鍵值對占用的內存空間。

釋放內存只是第一步，為了更加高效地管理內存空間，在應用程序釋放內存時，操作系統需要把釋放掉的內存塊插入一個空閑內存塊的鏈表，以便后續進行管理和再分配。這個過程本身需要一定時間，而且會阻塞當前釋放內存的應用程序。

所以，如果一下子釋放了大量內存，空閑內存塊鏈表操作時間就會增加，相應地就會造成 Redis 主線程的阻塞，如果主線程發生了阻塞，其他所有請求可能都會超時，超時越來越多，會造成 Redis 連接耗盡，產生各種異常。

刪除大 key 時建議采用分批次刪除和異步刪除的方式進行。

清空數據庫和上面 bigkey 刪除也是同樣道理，flushdb、flushall 也涉及到刪除和釋放所有的鍵值對，也是 Redis 的阻塞點。

Redis 集群可以進行節點的動態擴容縮容，這一過程目前還處于半自動狀態，需要人工介入。

在擴縮容的時候，需要進行數據遷移。而 Redis 為了保證遷移的一致性，遷移所有操作都是同步操作。

責任編輯：武曉燕來源：阿Q說代碼