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

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

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

命令阻塞

使用不當?shù)拿钤斐煽蛻舳俗枞?/p>

• keys * ：獲取所有的 key 操作；
• Hgetall：返回哈希表中所有的字段和；
• smembers：返回集合中的所有成員；

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

SAVE 阻塞

大家都知道 Redis 在進行 RDB 快照的時候，會調用系統(tǒng)函數(shù) fork() ，創(chuàng)建一個子線程來完成臨時文件的寫入，而觸發(fā)條件正是配置文件中的 save 配置。

當達到我們的配置時，就會觸發(fā) bgsave 命令創(chuàng)建快照，這種方式是不會阻塞主線程的，而手動執(zhí)行 save 命令會在主線程中執(zhí)行，阻塞主線程。

同步持久化

當 Redis 直接記錄 AOF 日志時，如果有大量的寫操作，并且配置為同步持久化

appendfsync always

即每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤，因為寫磁盤比較耗時，性能較差，所以有時會阻塞主線程。

AOF 重寫

• fork 出一條子線程來將文件重寫，在執(zhí)行 BGREWRITEAOF 命令時，Redis 服務器會維護一個 AOF 重寫緩沖區(qū)，該緩沖區(qū)會在子線程創(chuàng)建新 AOF 文件期間，記錄服務器執(zhí)行的所有寫命令。
• 當子線程完成創(chuàng)建新 AOF 文件的工作之后，服務器會將重寫緩沖區(qū)中的所有內容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的數(shù)據(jù)庫狀態(tài)與現(xiàn)有的數(shù)據(jù)庫狀態(tài)一致。
• 最后，服務器用新的 AOF 文件替換舊的 AOF 文件，以此來完成 AOF 文件重寫操作。

阻塞就是出現(xiàn)在第2步的過程中，將緩沖區(qū)中新數(shù)據(jù)寫到新文件的過程中會產(chǎn)生阻塞。

AOF 日志

AOF 的日志記錄不像關系型數(shù)據(jù)庫那樣在執(zhí)行命令之前記錄日志（方便故障恢復），而是采用先執(zhí)行命令后記錄日志的方式。

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

這是因為 AOF 日志也是在主線程中執(zhí)行的，如果在把日志文件寫入磁盤時，磁盤寫壓力大，就會導致寫盤很慢，進而導致后續(xù)的操作也無法執(zhí)行了。

大 Key 問題

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

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

• 客戶端超時阻塞：由于 Redis 執(zhí)行命令是單線程處理，然后在操作大 key 時會比較耗時，那么就會阻塞 Redis，從客戶端這一視角看，就是很久很久都沒有響應。
• 引發(fā)網(wǎng)絡阻塞：每次獲取大 key 產(chǎn)生的網(wǎng)絡流量較大，如果一個 key 的大小是 1 MB，每秒訪問量為 1000，那么每秒會產(chǎn)生 1000MB 的流量，這對于普通千兆網(wǎng)卡的服務器來說是災難性的。
• 阻塞工作線程：如果使用 del 刪除大 key 時，會阻塞工作線程，這樣就沒辦法處理后續(xù)的命令。

查找大 key

當我們在使用 Redis 自帶的 --bigkeys 參數(shù)查找大 key 時，最好選擇在從節(jié)點上執(zhí)行該命令，因為主節(jié)點上執(zhí)行時，會阻塞主節(jié)點。

• 我們還可以使用 SCAN 命令來查找大 key；

• 通過分析 RDB 文件來找出 big key，這種方案的前提是 Redis 采用的是 RDB 持久化。網(wǎng)上有現(xiàn)成的工具：

  • redis-rdb-tools：Python 語言寫的用來分析 Redis 的 RDB 快照文件用的工具
  • rdb_bigkeys：Go 語言寫的用來分析 Redis 的 RDB 快照文件用的工具，性能更好。

刪除大 key

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

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

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

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

清空數(shù)據(jù)庫

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

集群擴容

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

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

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

到此這篇關于淺談Redis阻塞的9種情況的文章就介紹到這了,更多相關Redis 阻塞內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論