Redis 是單執行緒的嗎？帶你全面瞭解 Redis
內容目錄
Redis 的單執行緒與多執行緒之爭為什麼 Redis 使用單執行緒Redis 單執行緒為什麼還那麼快Redis 6.0 引入多執行緒的原因Redis 的網路模型結語
哈嘍，大家好，我是小宋科技。今天在刷部落格的時候，看到一個挺有意思的面試題：“Redis 是單執行緒的嗎？”平時我們常聽說 Redis 是單執行緒的，但實際上，Redis 從 4.0 開始就部分引入了多執行緒機制。為什麼我們還說 Redis 是單執行緒的呢？
Redis 的單執行緒與多執行緒之爭
Redis 中存在非同步操作，例如 bgsave 命令，它允許在後臺非同步將當前資料持久化到磁碟。既然有非同步操作，自然涉及多執行緒，那為什麼還說 Redis 是單執行緒的呢？
實際上，平時所說的 Redis 是單執行緒的，主要是指 Redis 對外提供鍵值對儲存服務的核心功能，即網路請求和資料操作是由一個執行緒完成的。而其他例如持久化儲存、叢集支撐等模組可以由多執行緒完成。在 Redis 6.0 版本中，網路請求處理部分迎來了一次重大更新，引入了多執行緒模型。這意味著 Redis 在接收網路請求時，可以利用多個執行緒並行處理，從而大大提高併發效能。
為什麼 Redis 使用單執行緒
很多人認為“單執行緒”意味著“低效”。然而，Redis 採用單執行緒模型主要有三個原因：
- CPU 不是效能瓶頸：Redis 的操作基本都是基於記憶體的，因此 CPU 並不是瓶頸所在。
- 磁碟 IO 不是瓶頸：Redis 操作主要在記憶體中進行，很少涉及磁碟 IO。
- 網路 IO 是主要挑戰：早期設計者認為透過 IO 多路複用技術足以應對大部分場景。
多執行緒的引入雖然可以提高 IO 和 CPU 的利用率，但也會帶來併發問題和設計複雜性。因此，Redis 最終選擇了簡單的單執行緒模型。
Redis 單執行緒為什麼還那麼快
Redis 單執行緒模型能夠避免不同執行緒之間的資源競爭，同時減少執行緒切換的開銷。其高效性還體現在以下幾個方面：
- 高效的資料結構：Redis 的資料結構經過精心最佳化，具有極高的效率。
- 基於記憶體操作：所有操作都在記憶體中進行，極少的 IO 時間。
- IO 多路複用：透過一個執行緒監聽多個 IO 事件，加快 IO 利用率。
Redis 6.0 引入多執行緒的原因
Redis 6.0 引入的多執行緒主要針對處理網路請求。這是因為，隨著業務場景越來越複雜，有些公司需要更高的 QPS（每秒查詢率）。為了提升 QPS，很多公司會部署 Redis 叢集，並儘可能增加 Redis 機器數。但這種做法的資源消耗巨大。
經過分析，限制 Redis 效能的主要瓶頸在網路 IO 的處理上。多路複用的 IO 模型本質上是同步阻塞型 IO 模型，在處理網路請求時呼叫 select 的過程是阻塞的。為了充分利用 CPU 的多核優勢，Redis 6.0 引入多執行緒，使得網路請求處理併發進行，大大提升了效能。
Redis 的網路模型
Redis 的網路模型依然基於著名的 Reactor 模式。根據分發器和處理執行緒的數量，通常可以分為三種模式：
- 單分發器單執行緒：所有操作在同一個執行緒中完成。
- 單分發器多執行緒：資料的接收和傳送由多個執行緒完成，業務處理在子執行緒中進行。
- 多分發器多執行緒：多個分發器和多個執行緒處理請求。
Redis 6.0 採用單分發器多執行緒模型進行了一定改進：
- 接收和傳送資料納入子執行緒：避免高併發時主執行緒的處理能力成為瓶頸。
- 業務在主執行緒中執行：保持整體結構的一致性，減少修改成本。
結語
Redis 透過引入多執行緒，充分利用多核優勢，解決了網路 IO 瓶頸問題，大幅提升了併發效能。然而，核心的資料操作仍然由單執行緒完成，確保了簡單高效的設計。希望本文能幫助大家更好地理解 Redis 的單執行緒與多執行緒機制，也歡迎大家在評論區分享自己的見解和問題。
如果覺得本文對你有所幫助，請點贊、轉發、收藏，讓更多人瞭解 Redis 的魅力！
喜歡我的文章記得關注公眾號“小宋編碼”，我們下期再見！