淺談Redis的異步機制
前言
命令操作、系統配置、關鍵機制、硬件配置等會影響 Redis 的性能，不僅要知道具體的機制，盡可能避免性能異常的情況出現，還要提前準備好應對異常的方案。
Redis 內部的阻塞式操作：
- CPU 核和 NUMA 架構的影響；
- Redis 關鍵系統配置；
- Redis 內存碎片；
- Redis 緩沖區。
一、Redis 的阻塞點
和 Redis 實例交互的對象，以及交互時會發生的操作：
- 客戶端：網絡 IO，鍵值對增刪改查操作，數據庫操作；
- 磁盤：生成 RDB 快照，記錄 AOF 日志，AOF 日志重寫；
- 主從節點：主庫生成、傳輸 RDB 文件，從庫接收 RDB 文件、清空數據庫、加載 RDB 文件；
- 切片集群實例：向其他實例傳輸哈希槽信息，數據遷移。
4 類交互對象和具體的操作之間的關系：
和客戶端交互時的阻塞點：
網絡 IO 有時候會比較慢，但是 Redis 使用瞭 IO 多路復用機制，避免瞭主線程一直處在等待網絡連接或請求到來的狀態，所以網絡 IO 不是導致 Redis 阻塞的因素。
鍵值對的增刪改查操作是 Redis 和客戶端交互的主要部分，也是 Redis 主線程執行的主要任務。復雜度高的增刪改查操作肯定會阻塞 Redis。
判斷操作復雜度高低的標準：看操作的復雜度是否為 O(N)。
Redis 的第一個阻塞點：集合全量查詢和聚合操作：
Redis 中涉及集合的操作復雜度通常為 O(N)，使用時需重視起來。
例如集合元素全量查詢操作 HGETALL、SMEMBERS，以及集合的聚合統計操作，例如求交、並和差集。
Redis 的第二個阻塞點 :bigkey 刪除操作
集合自身的刪除操作同樣也有潛在的阻塞風險。刪除操作的本質是要釋放鍵值對占用的內存空間。 釋放內存隻是第一步，為瞭更加高效地管理內存空間，在應用程序釋放內存時，操作系統需要把釋放掉的內存塊插入一個空閑內存塊的鏈表，以便後續進行管理和再分配。
這個過程本身需要一定時間，而且會阻塞當前釋放內存的應用程序，如果一下子釋放瞭大量內存，空閑內存塊鏈表操作時間就會增加，相應地就會造成 Redis 主線程的阻塞。
釋放大量內存的時機：在刪除大量鍵值對數據的時候，刪除包含瞭大量元素的集合，也稱為 bigkey 刪除。
不同元素數量的集合在進行刪除操作時所消耗的時間：
得出三個結論：
- 當元素數量從 10 萬增加到 100 萬時，4 大集合類型的刪除時間的增長幅度從 5 倍上升到瞭近 20 倍；
- 集合元素越大，刪除所花費的時間就越長；
- 當刪除有 100 萬個元素的集合時，最大的刪除時間絕對值已經達到瞭 1.98s（Hash 類 型）。Redis 的響應時間一般在微秒級別，一個操作達到瞭近 2s，不可避免地會阻塞主線程。
Redis 的第三個阻塞點：清空數據庫
既然頻繁刪除鍵值對都是潛在的阻塞點瞭，在 Redis 的數據庫級別操作中，清空數據庫（例如 FLUSHDB 和 FLUSHALL 操作）也是一個潛在的阻塞風險，因為它涉及到刪除和釋放所有的鍵值對。
Redis 的第四個阻塞點：AOF 日志同步寫
磁盤 IO 一般都是比較費時費力的，需要重點關註。 Redis 開發者早已認識到磁盤 IO 會帶來阻塞，所以把 Redis 設計為采用子進程的方式生成 RDB 快照文件、執行 AOF 日志重寫操作。由子進程負責執行，慢速的磁盤 IO 就不會阻塞主線程瞭。
Redis 直接記錄 AOF 日志時，會根據不同的寫回策略對數據做落盤保存。一個同步寫磁盤的操作的耗時大約是 1～2ms，如果有大量的寫操作需要記錄在 AOF 日志中，並同步寫回的話，會阻塞主線程。
Redis 的第五個阻塞點：從庫加載 RDB 文件
在主從集群中，主庫需要生成 RDB 文件，並傳輸給從庫。
主庫在復制的過程中，創建和傳輸 RDB 文件都是由子進程來完成的，不會阻塞主線程。
但是從庫在接收瞭 RDB 文件後，需要使用 FLUSHDB 命令清空當前數據庫，正好撞上瞭第三個阻塞點。
從庫在清空當前數據庫後，需要把 RDB 文件加載到內存，這個過程的快慢和 RDB 文件的大小密切相關，RDB 文件越大，加載過程越慢。
切片集群實例交互時的阻塞點
部署 Redis 切片集群時，每個 Redis 實例上分配的哈希槽信息需要在不同實例間進行傳遞，當需要進行負載均衡或者有實例增刪時，數據會在不同的實例間進行遷移。不過哈希槽的信息量不大，而數據遷移是漸進式執行的，這兩類操作對 Redis 主線程的阻塞風險不大。
如果使用瞭 Redis Cluster 方案，而且同時正好遷移的是 bigkey 的話，就會造成主線程的阻塞，因為 Redis Cluster 使用瞭同步遷移。
五個阻塞點：
- 集合全量查詢和聚合操作；
- bigkey 刪除；
- 清空數據庫；
- AOF 日志同步寫；
- 從庫加載 RDB 文件。
二、可以異步執行的阻塞點
為瞭避免阻塞式操作，Redis 提供瞭異步線程機制：
Redis 會啟動一些子線程，然後把一些任務交給這些子線程，讓它們在後臺完成，而不再由主線程來執行這些任務。可以避免阻塞主線程。
異步執行對操作的要求：
一個能被異步執行的操作並不是 Redis 主線程的關鍵路徑上的操作（客戶端把請求發送給 Redis 後，等著 Redis 返回數據結果的操作）。
主線程接收到操作 1 後，操作 1 並不用給客戶端返回具體的數據，主線程可以把它交給後臺子線程來完成，同時隻要給客戶端返回一個“OK”結果就行。
在子線程執行操作 1 的時候，客戶端又向 Redis 實例發送瞭操作 2，客戶端是需要使用操作 2 返回的數據結果的，如果操作 2 不返回結果，那麼客戶端將一直處於等待狀態。
操作 1 就不算關鍵路徑上的操作，因為它不用給客戶端返回具體數據，所以可以由後臺子線程異步執行。
操作 2 需要把結果返回給客戶端，它就是關鍵路徑上的操作，所以主線程必須立即把這個操作執行完。
- Redis 讀操作是典型的關鍵路徑操作，因為客戶端發送瞭讀操作之後，就會等待讀取的數據返回，以便進行後續的數據處理。而 Redis 的第一個阻塞點“集合全量查詢 和聚合操作”都涉及到瞭讀操作，不能進行異步操作。
- 刪除操作並不需要給客戶端返回具體的數據結果，不算是關鍵路徑操作。“bigkey 刪除”和“清空數據庫”都是對數據做刪除，並不在關鍵路徑上。可以使用後臺子線程來異步執行刪除操作。
- “AOF 日志同步寫”，為瞭保證數據可靠性，Redis 實例需要保證 AOF 日志中的操作記錄已經落盤，這個操作雖然需要實例等待，但它並不會返回具體的數據結果給實例。所以可以啟動一個子線程來執行 AOF 日志的同步寫。
- “從庫加載 RDB 文件”要想對客戶端提供數據存取服務，就必須把 RDB 文件加載完成。這個操作也屬於關鍵路徑上的操作，必須讓從庫的主線程來執行。
除瞭“集合全量查詢和聚合操作”和“從庫加載 RDB 文 件”，其他三個阻塞點涉及的操作都不在關鍵路徑上，可以使用 Redis 的異步子線程機制來實現 bigkey 刪除，清空數據庫，以及 AOF 日志同步寫。
三、異步的子線程機制
Redis 主線程啟動後，會使用操作系統提供的 pthread_create 函數創建 3 個子線程，負責AOF 日志寫操作、鍵值對刪除、文件關閉的異步執行。
主線程通過一個鏈表形式的任務隊列和子線程進行交互。
當收到鍵值對刪除和清空數據庫的操作時，主線程會把這個操作封裝成一個任務，放入到任務隊列中，然後給客戶端返回一個完成信息，表明刪除已經完成。
但實際上，這個時候刪除還沒有執行，等到後臺子線程從任務隊列中讀取任務後，才開始實際刪除鍵值對，並釋放相應的內存空間。這種異步刪除也稱為惰性刪除 （lazy free）。
當 AOF 日志配置成 everysec 選項後，主線程會把 AOF 寫日志操作封裝成一個任務，也放到任務隊列中。後臺子線程讀取任務後，開始自行寫入 AOF 日志，主線程就不用一直等待 AOF 日志寫完瞭。
Redis 中的異步子線程執行機制：
異步的鍵值對刪除和數據庫清空操作是 Redis 4.0 後提供的功能，Redis 也提供瞭新的命令來執行這兩個操作：
- 鍵值對刪除：集合類型中有大量元素（例如有百萬級別或千萬級別元素）需要刪除時，建議使用 UNLINK 命令；
- 清空數據庫：可以在 FLUSHDB 和 FLUSHALL 命令後加上 ASYNC 選項，讓後臺子線程異步地清空數據庫。
FLUSHDB ASYNC FLUSHALL AYSNC
總結
Redis 實例運行時的 4 大類交互對象：客戶端、磁盤、主從庫實例、 切片集群實例。
基於這 4 大類交互對象導致 Redis 性能受損的 5 大阻塞點：集合全量查詢和聚合操作、bigkey 刪除、清空數據庫、AOF 日志同步寫、從庫加載 RDB 文件。
bigkey 刪除、清空數據庫、AOF 日志同步寫不屬於關鍵路徑操作， 可以使用異步子線程機制來完成。
Redis 在運行時會創建三個子線程，主線程會通過一個任務隊列和三個子線程進行交互。子線程會根據任務的具體類型，來執行相應的異步操作。
異步刪除操作是 Redis 4.0 以後才有的功能，如果使用的是 4.0 之前的版本，遇到 bigkey 刪除時，建議：先使用集合類型提供的 SCAN 命令讀取數據， 然後再進行刪除。因為用 SCAN 命令可以每次隻讀取一部分數據並進行刪除，這樣可以避免一次性刪除大量 key 給主線程帶來的阻塞。
例如，對於 Hash 類型的 bigkey 刪除，使用 HSCAN 命令，每次從 Hash 集合中獲取一部分鍵值對（例如 200 個），再使用 HDEL 刪除這些鍵值對，可以把刪除壓力分攤到多次操作中，每次刪除操作的耗時就不會太長，也就不會阻塞主線程瞭。
集合全量查詢和聚合操作、從庫加載 RDB 文件是在關鍵路徑上，無法使用異步操作來完成。
建議：
- 集合全量查詢和聚合操作：使用 SCAN 命令，分批讀取數據，再在客戶端進行聚合計算；
- 從庫加載 RDB 文件：把主庫的數據量大小控制在 2~4GB 左右，以保證 RDB 文件能以較快的速度加載。
到此這篇關於淺談Redis的異步機制的文章就介紹到這瞭,更多相關Redis 異步機制內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！