Redis 和 IO 多路複用

_吹雪_發表於2018-07-30
Redis

最近在看 UNIX 網路程式設計並研究了一下 Redis 的實現，感覺 Redis 的原始碼十分適合閱讀和分析，其中 I/O 多路複用（mutiplexing）部分的實現非常乾淨和優雅，在這裡想對這部分的內容進行簡單的整理。

幾種 I/O 模型

為什麼 Redis 中要使用 I/O 多路複用這種技術呢？

首先，Redis 是跑在單執行緒中的，所有的操作都是按照順序線性執行的， 但是由於讀寫操作等待使用者輸入或輸出都是阻塞的，所以 I/O 操作在一般情況下往往不能直接返回，這會導致某一檔案的 I/O 阻塞導致整個程式無法對其它客戶提供服務，而 I/O 多路複用就是為了解決這個問題而出現的。

Blocking I/O

先來看一下傳統的阻塞 I/O 模型到底是如何工作的：當使用 read 或者 write 對某一個檔案描述符（File Descriptor 以下簡稱 FD)進行讀寫時，如果當前 FD 不可讀或不可寫，整個 Redis 服務就不會對其它的操作作出響應，導致整個服務不可用。

這也就是傳統意義上的，也就是我們在程式設計中使用最多的阻塞模型：

阻塞模型雖然開發中非常常見也非常易於理解，但是由於它會影響其他 FD 對應的服務，所以在需要處理多個客戶端任務的時候，往往都不會使用阻塞模型。

I/O 多路複用

雖然還有很多其它的 I/O 模型，但是在這裡都不會具體介紹。

阻塞式的 I/O 模型並不能滿足這裡的需求，我們需要一種效率更高的 I/O 模型來支撐 Redis 的多個客戶（redis-cli），這裡涉及的就是 I/O 多路複用模型了：

在 I/O 多路複用模型中，最重要的函式呼叫就是 select，該方法的能夠同時監控多個檔案描述符的可讀可寫情況，當其中的某些檔案描述符可讀或者可寫時，select 方法就會返回可讀以及可寫的檔案描述符個數。

Reactor 設計模式

Redis 服務採用 Reactor 的方式來實現檔案事件處理器（每一個網路連線其實都對應一個檔案描述符）

檔案事件處理器使用 I/O 多路複用模組同時監聽多個 FD，當 accept、read、write 和 close 檔案事件產生時，檔案事件處理器就會回撥 FD 繫結的事件處理器。

雖然整個檔案事件處理器是在單執行緒上執行的，但是通過 I/O 多路複用模組的引入，實現了同時對多個 FD 讀寫的監控，提高了網路通訊模型的效能，同時也可以保證整個 Redis 服務實現的簡單。

I/O 多路複用模組

I/O 多路複用模組封裝了底層的 select、epoll、avport 以及 kqueue 這些 I/O 多路複用函式，為上層提供了相同的介面。

簡要了解該模組的功能，整個 I/O 多路複用模組抹平了不同平臺上 I/O 多路複用函式的差異性，提供了相同的介面.

子模組的選擇

因為 Redis 需要在多個平臺上執行，同時為了最大化執行的效率與效能，所以會根據編譯平臺的不同選擇不同的 I/O 多路複用函式作為子模組，提供給上層統一的介面；在 Redis 中，我們通過巨集定義的使用，合理的選擇不同的子模組

因為 select 函式是作為 POSIX 標準中的系統呼叫，在不同版本的作業系統上都會實現，所以將其作為保底方案：

Redis 會優先選擇時間複雜度為 O(1) 的 I/O 多路複用函式作為底層實現，包括 Solaries 10 中的 evport、Linux 中的 epoll 和 macOS/FreeBSD 中的 kqueue，上述的這些函式都使用了核心內部的結構，並且能夠服務幾十萬的檔案描述符。

但是如果當前編譯環境沒有上述函式，就會選擇 select 作為備選方案，由於其在使用時會掃描全部監聽的描述符，所以其時間複雜度較差 O(n)，並且只能同時服務 1024 個檔案描述符，所以一般並不會以 select 作為第一方案使用。

總結

Redis 對於 I/O 多路複用模組的設計非常簡潔，通過巨集保證了 I/O 多路複用模組在不同平臺上都有著優異的效能，將不同的 I/O 多路複用函式封裝成相同的 API 提供給上層使用。

整個模組使 Redis 能以單程式執行的同時服務成千上萬個檔案描述符，避免了由於多程式應用的引入導致程式碼實現複雜度的提升，減少了出錯的可能性。

問答

  1. Redis為什麼是單執行緒 ？
    因為CPU不是Redis的瓶頸。Redis的瓶頸最有可能是機器記憶體或者網路頻寬。（以上主要來自官方FAQ）既然單執行緒容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單執行緒的方案了。關於redis的效能，官方網站也有，普通筆記本輕鬆處理每秒幾十萬的請求，參見：How fast is Redis?(https://link.zhihu.com/?target=https%3A//redis.io/topics/benchmarks)

  2. 如果萬一CPU成為你的Redis瓶頸了，或者，你就是不想讓伺服器其他核閒置，那怎麼辦？
    那也很簡單，你多起幾個Redis程式就好了。Redis是keyvalue資料庫，又不是關聯式資料庫，資料之間沒有約束。只要客戶端分清哪些key放在哪個Redis程式上就可以了。redis-cluster可以幫你做的更好。

  3. 單執行緒模型
    Redis客戶端對服務端的每次呼叫都經歷了傳送命令，執行命令，返回結果三個過程。其中執行命令階段，由於Redis是單執行緒來處理命令的，所有每一條到達服務端的命令不會立刻執行，所有的命令都會進入一個佇列中，然後逐個被執行。並且多個客戶端傳送的命令的執行順序是不確定的。但是可以確定的是不會有兩條命令被同時執行，不會產生併發問題，這就是Redis的單執行緒基本模型。

  4. 單執行緒模型每秒萬級別處理能力的原因
    （1）純記憶體訪問。 資料存放在記憶體中，記憶體的響應時間大約是 100納秒 ，這是Redis每秒萬億級別訪問的重要基礎。
    （2）非阻塞I/O ，Redis採用epoll做為I/O多路複用技術的實現 ，再加上Redis自身的事件處理模型將epoll中的連線，讀寫，關閉都轉換為了時間，不在I/O上浪費過多的時間。
    （3）單執行緒 避免了執行緒切換和競態產生的消耗 。
    （4）Redis採用單執行緒模型，每條命令執行如果佔用大量時間， 會造成其他執行緒阻塞，對於Redis這種高效能服務是致命的，所以Redis是面向高速執行的資料庫。

內部實現採用epoll，採用了epoll+自己實現的簡單的事件框架。 epoll中的讀、寫、關閉、連線都轉化成了事件，然後利用epoll的多路複用特性， 絕不在io上浪費一點時間

這3個條件不是相互獨立的，特別是第一條，如果請求都是耗時的，採用單執行緒吞吐量及效能可想而知了。應該說redis為特殊的場景選擇了合適的技術方案。

參考：
https://draveness.me/redis-io-multiplexing
https://blog.csdn.net/sunhuiliang85/article/details/73656830

相關文章