哈嘍大家好，我是阿Q！

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

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

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

命令阻塞

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

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

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

SAVE 阻塞

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

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

同步持久化

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

appendfsync always

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

AOF 重寫

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

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

AOF 日志

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

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

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

大 Key 問題

大 key 并不是指 key 的值很大，而是 key 對應(yīng)的 value 很大。

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

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

查找大 key

當(dāng)我們在使用 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

刪除操作的本質(zhì)是要釋放鍵值對占用的內(nèi)存空間。

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

所以，如果一下子釋放了大量內(nèi)存，空閑內(nèi)存塊鏈表操作時間就會增加，相應(yīng)地就會造成 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 的內(nèi)存使用過大，嚴(yán)重的時候會觸發(fā)集群內(nèi)的故障轉(zhuǎn)移，造成不必要的切換。