Redis 使用了單線程架構、非阻塞 I/O 、多路復用模型來實現高性能的內存數據庫服務。Redis 是單線程的。那么為什么說是單線程呢？

Redis 在 Reactor 模型內開發了事件處理器，這個事件處理器分為多個 Socket（套接字）、IO 多路復用程序、事件分派器、事件處理器（連接應答處理器、命令請求處理器、命令回復處理器），其中事件派發器的隊列是由單線程的事件處理器消費的，也是因為這個，Redis 才叫單線程模型。

當多個事件并發出現時，I/O 多路復用程序將監聽到的所有 Socket，關聯不同的事件處理器，這個關聯操作以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向事件分派器傳送 Socket，當上一個套接字產生的事件被處理完畢之后，I/O 多路復用程序才會繼續向事件分派器傳送下一個套接字。

1. 單線程模型

開啟三個 redis-cli 客戶端同時執行命令。客戶端 1 設置一個字符串鍵值對：

127.0.0.1:6379> set hello world

客戶端 2 對 counter 做自增操作：

127.0.0.1:6379> incr counter

客戶端 3 對 counter 做自增操作：

127.0.0.1:6379> incr counter

Redis 客戶端與服務端的模型可以簡化成下圖，每次客戶端調用都經歷了發送命令、執行命令、返回結果三個過程。

其中第 2 步是重點要討論的，因為 Redis 是單線程來處理命令的，所以一條命令從客戶端達到服務端不會立刻被執行，所有命令都會進入一個隊列中，然后逐個被執行。

所以上面 3 個客戶端命令的執行順序是不確定的，如下圖所示。但是可以確定不會有兩條命令被同時執行

所以兩條 incr 命令無論怎么執行最終結果都是 2，不會產生并發問題，這就是 Redis 單線程的基本模型。

2. 非阻塞 IO

當我們調用套接字的讀寫方法，默認它們是阻塞的，比如 read 方法要傳遞進去一個參數 n，表示最多讀取這么多字節后再返回，如果一個字節都沒有，那么線程就會卡在那里，直到新的數據到來或者連接關閉了，read 方法才可以返回，線程才能繼續處理。而 write 方法一般來說不會阻塞，除非內核為套接字分配的寫緩沖區已經滿了，write 方法就會阻塞，直到緩存區中有空閑空間挪出來了。

非阻塞 IO 在套接字對象上提供了一個選項 Non_Blocking，當這個選項打開時，讀寫方法不會阻塞，而是能讀多少讀多少，能寫多少寫多少。能讀多少取決于內核為套接字分配的讀緩沖區內部的數據字節數，能寫多少取決于內核為套接字分配的寫緩沖區的空閑空間字節數。讀方法和寫方法都會通過返回值來告知程序實際讀寫了多少字節。

有了非阻塞 IO 意味著線程在讀寫 IO 時可以不必再阻塞了，讀寫可以瞬間完成然后線程可以繼續干別的事了。

3. 多路復用（事件輪詢）

非阻塞 IO 有個問題，那就是線程要讀數據，結果讀了一部分就返回了，線程如何知道何時才應該繼續讀。也就是當數據到來時，線程如何得到通知。寫也是一樣，如果緩沖區滿了，寫不完，剩下的數據何時才應該繼續寫，線程也應該得到通知。

事件輪詢 API 就是用來解決這個問題的，最簡單的事件輪詢 API 是 select 函數，它是操作系統提供給用戶程序的 API。輸入是讀寫描述符列表 read_fds & write_fds，輸出是與之對應的可讀可寫事件。同時還提供了一個 timeout 參數，如果沒有任何事件到來，那么就最多等待 timeout 時間，線程處于阻塞狀態。一旦期間有任何事件到來，就可以立即返回。時間過了之后還是沒有任何事件到來，也會立即返回。拿到事件后，線程就可以繼續挨個處理相應的事件。處理完了繼續過來輪詢。于是線程就進入了一個死循環，我們把這個死循環稱為事件循環，一個循環為一個周期。

每個客戶端套接字 socket 都有對應的讀寫文件描述符。

read_events, write_events = select(read_fds, write_fds, timeout)
for event in read_events:handle_read(event.fd)
for event in write_events:handle_write(event.fd)
handle_others()  # 處理其它事情，如定時任務等

因為我們通過 select 系統調用同時處理多個通道描述符的讀寫事件，因此我們將這類系統調用稱為多路復用 API 。

現代操作系統的多路復用 API 已經不再使用 select 系統調用，而改用 epoll(linux) 和 kqueue(freebsd & macosx)，因為 select 系統調用的性能在描述符特別多時性能會非常差。它們使用起來可能在形式上略有差異，但是本質上都是差不多的，都可以使用上面的偽代碼邏輯進行理解。

服務器套接字 serversocket 對象的讀操作是指調用 accept 接受客戶端新連接。何時有新連接到來，也是通過 select 系統調用的讀事件來得到通知的。

4. 為什么單線程還能如此快

為什么 Redis 使用單線程模型會達到每秒萬級別的處理能力呢？可以將其歸結為三點：

1. 純內存訪問，Redis 將所有數據放在內存中，內存的響應時長大約為 100 納秒，這是 Redis 達到每秒萬級別訪問的重要基礎。
2. 非阻塞 I/O，Redis 使用 epoll 作為 I/O 多路復用技術的實現，再加上 Redis 自身的事件處理模型將 epoll 中的連接、讀寫、關閉都轉換為件，不在網絡 I/O 上浪費過多的時間。
3. 單線程避免了線程切換和競態產生的消耗。

單線程能帶來幾個好處：

1. 單線程可以簡化數據結構和算法的實現。如果對高級編程語言熟悉的讀者應該了解并發數據結構實現不但困難而且開發測試比較麻煩。
2. 單線程避免了線程切換和競態產生的消耗，對于服務端開發來說，鎖和線程切換通常是性能殺手。

但是單線程會有一個問題：對于每個命令的執行時間是有要求的。如果某個命令執行過長，會造成其他命令的阻塞，對于 Redis 這種高性能的服務來說是致命的，所以 Redis 是面向快速執行場景的數據庫。

5. 多個異步線程

5.1 懶惰刪除

在 4.0 版本引入了 unlink 指令，它能對刪除操作進行懶處理，丟給后臺線程來異步回收內存。

> unlink key
OK

可以將整個 Redis 內存里面所有有效的數據想象成一棵大樹。當 unlink 指令發出時，它只是把大樹中的一個樹枝別斷了，然后扔到旁邊的火堆里焚燒 (異步線程池)。樹枝離開大樹的一瞬間，它就再也無法被主線程中的其它指令訪問到了，因為主線程只會沿著這顆大樹來訪問。

Redis 提供了 flushdb 和 flushall 指令，用來清空數據庫，這也是極其緩慢的操作。Redis 4.0 同樣給這兩個指令也帶來了異步化，在指令后面增加 async 參數就可以將整棵大樹連根拔起，扔給后臺線程慢慢焚燒。

> flushall async
OK

5.2 異步隊列

主線程將對象的引用從「大樹」中摘除后，會將這個 key 的內存回收操作包裝成一個任務，塞進異步任務隊列，后臺線程會從這個異步隊列中取任務。任務隊列被主線程和異步線程同時操作，所以必須是一個線程安全的隊列。

不是所有的 unlink 操作都會延后處理，如果對應 key 所占用的內存很小，延后處理就沒有必要了，這時候 Redis 會將對應的 key 內存立即回收，跟 del 指令一樣。

5.3 其它異步刪除點

Redis 回收內存除了 del 指令和 flush 之外，還會存在于在 key 的過期、LRU 淘汰、rename 指令以及從庫全量同步時接受完 rdb 文件后會立即進行的 flush 操作。

Redis4.0 為這些刪除點也帶來了異步刪除機制，打開這些點需要額外的配置選項。

• slave-lazy-flush 從庫接受完 rdb 文件后的 flush 操作
• lazyfree-lazy-eviction 內存達到 maxmemory 時進行淘汰
• lazyfree-lazy-expire key 過期刪除
• lazyfree-lazy-server-del rename 指令刪除 destKey

參考：

• 《Redis 開發運維》
• https://juejin.cn/book/6844733724618129422/section/6844733724710420487

總結

以上是生活随笔為你收集整理的Redis 笔记（12）— 单线程架构（非阻塞 IO、多路复用）和多个异步线程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。