快捷導航

淺談Redis的異步機制

更新時間：2022年05月13日 10:23:50 作者：海陸云

命令操作、系統(tǒng)配置、關(guān)鍵機制、硬件配置等會影響 Redis 的性能，還要提前準備好應對異常的方案，本文主要介紹了Redis的異步機制，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧

前言

命令操作、系統(tǒng)配置、關(guān)鍵機制、硬件配置等會影響 Redis 的性能，不僅要知道具體的機制，盡可能避免性能異常的情況出現(xiàn)，還要提前準備好應對異常的方案。

Redis 內(nèi)部的阻塞式操作：

CPU 核和 NUMA 架構(gòu)的影響；
Redis 關(guān)鍵系統(tǒng)配置；
Redis 內(nèi)存碎片；
Redis 緩沖區(qū)。

一、Redis 的阻塞點

和 Redis 實例交互的對象，以及交互時會發(fā)生的操作：

客戶端：網(wǎng)絡(luò) IO，鍵值對增刪改查操作，數(shù)據(jù)庫操作；
磁盤：生成 RDB 快照，記錄 AOF 日志，AOF 日志重寫；
主從節(jié)點：主庫生成、傳輸 RDB 文件，從庫接收 RDB 文件、清空數(shù)據(jù)庫、加載 RDB 文件；
切片集群實例：向其他實例傳輸哈希槽信息，數(shù)據(jù)遷移。

4 類交互對象和具體的操作之間的關(guān)系：

和客戶端交互時的阻塞點：

網(wǎng)絡(luò) IO 有時候會比較慢，但是 Redis 使用了 IO 多路復用機制，避免了主線程一直處在等待網(wǎng)絡(luò)連接或請求到來的狀態(tài)，所以網(wǎng)絡(luò) IO 不是導致 Redis 阻塞的因素。

鍵值對的增刪改查操作是 Redis 和客戶端交互的主要部分，也是 Redis 主線程執(zhí)行的主要任務(wù)。復雜度高的增刪改查操作肯定會阻塞 Redis。

判斷操作復雜度高低的標準：看操作的復雜度是否為 O(N)。

Redis 的第一個阻塞點：集合全量查詢和聚合操作：

Redis 中涉及集合的操作復雜度通常為 O(N)，使用時需重視起來。
例如集合元素全量查詢操作 HGETALL、SMEMBERS，以及集合的聚合統(tǒng)計操作，例如求交、并和差集。

Redis 的第二個阻塞點 :bigkey 刪除操作

集合自身的刪除操作同樣也有潛在的阻塞風險。刪除操作的本質(zhì)是要釋放鍵值對占用的內(nèi)存空間。釋放內(nèi)存只是第一步，為了更加高效地管理內(nèi)存空間，在應用程序釋放內(nèi)存時，操作系統(tǒng)需要把釋放掉的內(nèi)存塊插入一個空閑內(nèi)存塊的鏈表，以便后續(xù)進行管理和再分配。

這個過程本身需要一定時間，而且會阻塞當前釋放內(nèi)存的應用程序，如果一下子釋放了大量內(nèi)存，空閑內(nèi)存塊鏈表操作時間就會增加，相應地就會造成 Redis 主線程的阻塞。

釋放大量內(nèi)存的時機：在刪除大量鍵值對數(shù)據(jù)的時候，刪除包含了大量元素的集合，也稱為 bigkey 刪除。

不同元素數(shù)量的集合在進行刪除操作時所消耗的時間：

得出三個結(jié)論：

當元素數(shù)量從 10 萬增加到 100 萬時，4 大集合類型的刪除時間的增長幅度從 5 倍上升到了近 20 倍；
集合元素越大，刪除所花費的時間就越長；
當刪除有 100 萬個元素的集合時，最大的刪除時間絕對值已經(jīng)達到了 1.98s（Hash 類型）。Redis 的響應時間一般在微秒級別，一個操作達到了近 2s，不可避免地會阻塞主線程。

Redis 的第三個阻塞點：清空數(shù)據(jù)庫

既然頻繁刪除鍵值對都是潛在的阻塞點了，在 Redis 的數(shù)據(jù)庫級別操作中，清空數(shù)據(jù)庫（例如 FLUSHDB 和 FLUSHALL 操作）也是一個潛在的阻塞風險，因為它涉及到刪除和釋放所有的鍵值對。

Redis 的第四個阻塞點：AOF 日志同步寫

磁盤 IO 一般都是比較費時費力的，需要重點關(guān)注。 Redis 開發(fā)者早已認識到磁盤 IO 會帶來阻塞，所以把 Redis 設(shè)計為采用子進程的方式生成 RDB 快照文件、執(zhí)行 AOF 日志重寫操作。由子進程負責執(zhí)行，慢速的磁盤 IO 就不會阻塞主線程了。

Redis 直接記錄 AOF 日志時，會根據(jù)不同的寫回策略對數(shù)據(jù)做落盤保存。一個同步寫磁盤的操作的耗時大約是 1～2ms，如果有大量的寫操作需要記錄在 AOF 日志中，并同步寫回的話，會阻塞主線程。

Redis 的第五個阻塞點：從庫加載 RDB 文件

在主從集群中，主庫需要生成 RDB 文件，并傳輸給從庫。

主庫在復制的過程中，創(chuàng)建和傳輸 RDB 文件都是由子進程來完成的，不會阻塞主線程。
但是從庫在接收了 RDB 文件后，需要使用 FLUSHDB 命令清空當前數(shù)據(jù)庫，正好撞上了第三個阻塞點。

從庫在清空當前數(shù)據(jù)庫后，需要把 RDB 文件加載到內(nèi)存，這個過程的快慢和 RDB 文件的大小密切相關(guān)，RDB 文件越大，加載過程越慢。

切片集群實例交互時的阻塞點

部署 Redis 切片集群時，每個 Redis 實例上分配的哈希槽信息需要在不同實例間進行傳遞，當需要進行負載均衡或者有實例增刪時，數(shù)據(jù)會在不同的實例間進行遷移。不過哈希槽的信息量不大，而數(shù)據(jù)遷移是漸進式執(zhí)行的，這兩類操作對 Redis 主線程的阻塞風險不大。

如果使用了 Redis Cluster 方案，而且同時正好遷移的是 bigkey 的話，就會造成主線程的阻塞，因為 Redis Cluster 使用了同步遷移。

五個阻塞點：

集合全量查詢和聚合操作；
bigkey 刪除；
清空數(shù)據(jù)庫；
AOF 日志同步寫；
從庫加載 RDB 文件。

二、可以異步執(zhí)行的阻塞點

為了避免阻塞式操作，Redis 提供了異步線程機制：

Redis 會啟動一些子線程，然后把一些任務(wù)交給這些子線程，讓它們在后臺完成，而不再由主線程來執(zhí)行這些任務(wù)?？梢员苊庾枞骶€程。

異步執(zhí)行對操作的要求：

一個能被異步執(zhí)行的操作并不是 Redis 主線程的關(guān)鍵路徑上的操作（客戶端把請求發(fā)送給 Redis 后，等著 Redis 返回數(shù)據(jù)結(jié)果的操作）。

主線程接收到操作 1 后，操作 1 并不用給客戶端返回具體的數(shù)據(jù)，主線程可以把它交給后臺子線程來完成，同時只要給客戶端返回一個“OK”結(jié)果就行。
在子線程執(zhí)行操作 1 的時候，客戶端又向 Redis 實例發(fā)送了操作 2，客戶端是需要使用操作 2 返回的數(shù)據(jù)結(jié)果的，如果操作 2 不返回結(jié)果，那么客戶端將一直處于等待狀態(tài)。

操作 1 就不算關(guān)鍵路徑上的操作，因為它不用給客戶端返回具體數(shù)據(jù)，所以可以由后臺子線程異步執(zhí)行。
操作 2 需要把結(jié)果返回給客戶端，它就是關(guān)鍵路徑上的操作，所以主線程必須立即把這個操作執(zhí)行完。

Redis 讀操作是典型的關(guān)鍵路徑操作，因為客戶端發(fā)送了讀操作之后，就會等待讀取的數(shù)據(jù)返回，以便進行后續(xù)的數(shù)據(jù)處理。而 Redis 的第一個阻塞點“集合全量查詢和聚合操作”都涉及到了讀操作，不能進行異步操作。
刪除操作并不需要給客戶端返回具體的數(shù)據(jù)結(jié)果，不算是關(guān)鍵路徑操作。“bigkey 刪除”和“清空數(shù)據(jù)庫”都是對數(shù)據(jù)做刪除，并不在關(guān)鍵路徑上?？梢允褂煤笈_子線程來異步執(zhí)行刪除操作。
“AOF 日志同步寫”，為了保證數(shù)據(jù)可靠性，Redis 實例需要保證 AOF 日志中的操作記錄已經(jīng)落盤，這個操作雖然需要實例等待，但它并不會返回具體的數(shù)據(jù)結(jié)果給實例。所以可以啟動一個子線程來執(zhí)行 AOF 日志的同步寫。
“從庫加載 RDB 文件”要想對客戶端提供數(shù)據(jù)存取服務(wù)，就必須把 RDB 文件加載完成。這個操作也屬于關(guān)鍵路徑上的操作，必須讓從庫的主線程來執(zhí)行。

除了“集合全量查詢和聚合操作”和“從庫加載 RDB 文件”，其他三個阻塞點涉及的操作都不在關(guān)鍵路徑上，可以使用 Redis 的異步子線程機制來實現(xiàn) bigkey 刪除，清空數(shù)據(jù)庫，以及 AOF 日志同步寫。

三、異步的子線程機制

Redis 主線程啟動后，會使用操作系統(tǒng)提供的 pthread_create 函數(shù)創(chuàng)建 3 個子線程，負責AOF 日志寫操作、鍵值對刪除、文件關(guān)閉的異步執(zhí)行。

主線程通過一個鏈表形式的任務(wù)隊列和子線程進行交互。

當收到鍵值對刪除和清空數(shù)據(jù)庫的操作時，主線程會把這個操作封裝成一個任務(wù)，放入到任務(wù)隊列中，然后給客戶端返回一個完成信息，表明刪除已經(jīng)完成。

但實際上，這個時候刪除還沒有執(zhí)行，等到后臺子線程從任務(wù)隊列中讀取任務(wù)后，才開始實際刪除鍵值對，并釋放相應的內(nèi)存空間。這種異步刪除也稱為惰性刪除 （lazy free）。

當 AOF 日志配置成 everysec 選項后，主線程會把 AOF 寫日志操作封裝成一個任務(wù)，也放到任務(wù)隊列中。后臺子線程讀取任務(wù)后，開始自行寫入 AOF 日志，主線程就不用一直等待 AOF 日志寫完了。

Redis 中的異步子線程執(zhí)行機制：

異步的鍵值對刪除和數(shù)據(jù)庫清空操作是 Redis 4.0 后提供的功能，Redis 也提供了新的命令來執(zhí)行這兩個操作：

鍵值對刪除：集合類型中有大量元素（例如有百萬級別或千萬級別元素）需要刪除時，建議使用 UNLINK 命令；
清空數(shù)據(jù)庫：可以在 FLUSHDB 和 FLUSHALL 命令后加上 ASYNC 選項，讓后臺子線程異步地清空數(shù)據(jù)庫。

FLUSHDB ASYNC 
FLUSHALL AYSNC

總結(jié)

Redis 實例運行時的 4 大類交互對象：客戶端、磁盤、主從庫實例、切片集群實例。

基于這 4 大類交互對象導致 Redis 性能受損的 5 大阻塞點：集合全量查詢和聚合操作、bigkey 刪除、清空數(shù)據(jù)庫、AOF 日志同步寫、從庫加載 RDB 文件。

bigkey 刪除、清空數(shù)據(jù)庫、AOF 日志同步寫不屬于關(guān)鍵路徑操作，可以使用異步子線程機制來完成。

Redis 在運行時會創(chuàng)建三個子線程，主線程會通過一個任務(wù)隊列和三個子線程進行交互。子線程會根據(jù)任務(wù)的具體類型，來執(zhí)行相應的異步操作。

異步刪除操作是 Redis 4.0 以后才有的功能，如果使用的是 4.0 之前的版本，遇到 bigkey 刪除時，建議：先使用集合類型提供的 SCAN 命令讀取數(shù)據(jù)，然后再進行刪除。因為用 SCAN 命令可以每次只讀取一部分數(shù)據(jù)并進行刪除，這樣可以避免一次性刪除大量 key 給主線程帶來的阻塞。
例如，對于 Hash 類型的 bigkey 刪除，使用 HSCAN 命令，每次從 Hash 集合中獲取一部分鍵值對（例如 200 個），再使用 HDEL 刪除這些鍵值對，可以把刪除壓力分攤到多次操作中，每次刪除操作的耗時就不會太長，也就不會阻塞主線程了。

集合全量查詢和聚合操作、從庫加載 RDB 文件是在關(guān)鍵路徑上，無法使用異步操作來完成。
建議：