如果面試官問我：Redis為什麼這麼快？

我肯定會說：因為Redis是記憶體資料庫！如果不是直接把資料放在記憶體裡，甭管怎麼最佳化資料結構、設計怎樣的網路I/O模型，都不可能達到如今這般的執行效率。

但是這麼回答多半會讓我直接回去等通知了。。。因為面試官想聽到的就是資料結構和網路模型方面的回答，雖然這兩者只是在記憶體基礎上的錦上添花。

說這些並非為了強調網路模型並不重要，恰恰相反，它是Redis實現高吞吐量的重要底層支撐，是“高效能”的重要原因，卻不是“快”的直接理由。

本文將從BIO開始介紹，經過NIO、多路複用，最終說回Redis的Reactor模型，力求詳盡。本文與其他文章的不同點主要在於：

1、不會介紹同步阻塞I/O、同步非阻塞I/O、非同步阻塞I/O、非同步非阻塞I/O等概念，這些術語只是對底層原理的一些概念總結而已，我覺得沒有用。底層原理搞懂了，這些概念根本不重要，我希望讀完本文之後，各位能夠不再糾結這些概念。

2、不會只拿生活中例子來說明問題。之前看過特別多的文章，這些文章舉的“燒水”、“取快遞”的例子真的是深入淺出，但是看懂這些例子會讓我們有一種我們真的懂了的錯覺。尤其對於網路I/O模型而言，很難找到生活中非常貼切的例子，這種例子不過是已經懂了的人高屋建瓴，對外輸出的一種形式，但是對於一知半解的讀者而言卻猶如鈍刀殺人。

牛皮已經吹出去了，正文開始。

1. 一次I/O到底經歷了什麼

我們都知道，網路I/O是透過Socket實現的，在說明網路I/O之前，我們先來回顧（瞭解）一下本地I/O的流程。

舉一個非常簡單的例子，下面的程式碼實現了檔案的複製，將file1.txt的資料複製到file2.txt中：

public static void main(String[] args) throws Exception {
  
    FileInputStream in = new FileInputStream("/tmp/file1.txt");
    FileOutputStream out = new FileOutputStream("/tmp/file2.txt");

    byte[] buf = new byte[in.available()];
    in.read(buf);
    out.write(buf);
}

這個I/O操作在底層到底經歷了什麼呢？下圖給出了說明：

大致可以概括為如下幾個過程：

in.read(buf)執行時，程式向核心發起 read()系統呼叫；
作業系統發生上下文切換，由使用者態(User mode)切換到核心態(Kernel mode)，把資料讀取到核心緩衝區（buffer）中；
核心把資料從核心空間複製到使用者空間，同時由核心態轉為使用者態；
繼續執行 out.write(buf)；
再次發生上下文切換，將資料從使用者空間buffer複製到核心空間buffer中，由核心把資料寫入檔案。

之所以先拿本地I/O舉個例子，是因為我想說明I/O模型並非僅僅針對網路IO（雖然網路I/O最常被我們拿來舉例），本地I/O同樣受到I/O模型的約束。比如在這個例子中，本地I/O用的就是典型的BIO，至於什麼是BIO，稍安勿躁，接著往下看。

除此之外，透過本地I/O，我還想向各位說明下面幾件事情：

我們編寫的程式本身並不能對檔案進行讀寫操作，這個步驟必須依賴於作業系統，換個詞兒就是「核心」；
一個看似簡單的I/O操作卻在底層引發了多次的使用者空間和核心空間的切換，並且資料在核心空間和使用者空間之間複製來複製去。

不同於本地I/O是從本地的檔案中讀取資料，網路I/O是透過網路卡讀取網路中的資料，網路I/O需要藉助Socket來完成，所以接下來我們重新認識一下Socket。

2. 什麼是Socket

這部分在一定程度上是我的強迫症作祟，我關於文章對知識點講解的完備性上對自己近乎苛刻。我覺得把Socket講明白對接下來的講解是一件很重要的事情，看過我之前的文章的讀者或許能意識到，我儘量避免把前置知識直接以連結的形式展示出來，我認為會割裂整篇文章的閱讀體驗。
不割裂的結果就是文章可能顯得很囉嗦，好像一件事情非得從盤古開天闢地開始講起。因此，如果各位覺得對這個知識點有足夠的把握，就直接略過好了～

我們所做的任何需要和遠端裝置進行互動的操作，並非是操作軟體本身進行的資料通訊。舉個例子就是我們用瀏覽器刷B站影片的時候，並非是瀏覽器自身向B站請求影片資料的，而是必須委託作業系統核心中的協議棧。

協議棧就是下邊這些書的程式碼實現，裡邊包含了TCP/IP及其他各種網路實現細節，這樣解釋應該好理解吧。

而Socket庫就是作業系統提供給我們的，用於呼叫協議棧網路功能的一堆程式元件的集合，也就是我們平時聽過的作業系統庫函式，Socket庫和協議棧的關係如下圖所示。

使用者程式向作業系統核心的協議棧發出委託時，需要按照指定的順序來呼叫 Socket 庫中的程式元件。

本文的所有案例都以TCP協議為例進行講解。

大家可以把資料收發想象成在兩臺計算機之間建立了一條資料通道，計算機透過這條通道進行資料收發的雙向操作，當然，這條通道是邏輯上的，並非實際存在。

資料透過管道流動這個比較好理解，但是問題在於這條管道雖然只是邏輯上存在，但是這個“邏輯”也不是光用腦袋想想就會出現的。就好比我們手機打電話，你總得先把號碼撥出去呀。

對應到網路I/O中，就意味著雙方必須建立各自的資料出入口，然後將兩個資料出入口像連線水管一樣接通，這個資料出入口就是上圖中的套接字，就是大名鼎鼎的socket。

客戶端和服務端之間的通訊可以被概括為如下4個步驟：

服務端建立socket，等待客戶端連線（建立socket階段）；
客戶端建立socket，連線到服務端（連線階段）；
收發資料（通訊階段）；
斷開管道並刪除socket（斷開連線）。

每一步都是透過特定語言的API呼叫Socket庫，Socket庫委託協議棧進行操作的。socket就是呼叫Socket庫中程式元件之後的產成品，比如Java中的ServerSocket，本質上還是呼叫作業系統的Socket庫，因此下文的程式碼例項雖然採用Java語言，但是希望各位讀者注意：只有語法上抽象與具體的區別，socket的操作邏輯是完全一致的。

但是，我還是得花點口舌囉嗦一下這幾個步驟的一些細節，為了不至於太枯燥，接下來將這4個步驟和BIO一起講解。

3. 阻塞I/O（Blocking I/O，BIO）

我們先從比較簡單的客戶端開始談起。

3.1 客戶端的socket流程

public class BlockingClient {
    public static void main(String[] args) {

        try {
            // 建立套接字 & 建立連線
            Socket socket = new Socket("localhost", 8099);
            // 向服務端寫資料
            BufferedWriter bufferedWriter = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
            bufferedWriter.write("我是客戶端，收到請回答！！\n");
            bufferedWriter.flush();

            BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            String line = bufferedReader.readLine();
            System.out.println("收到服務端返回的資料：" + line);
        } catch (IOException e) {
            // 錯誤處理
        }
    }
}

上面展示了一段非常簡單的Java BIO的客戶端程式碼，相信你們一定不會感到陌生，接下來我們一點點分析客戶端的socket操作究竟做了什麼。

Socket socket = new Socket("localhost", 8099);

雖然只是簡單的一行語句，但是其中包含了兩個步驟，分別是建立套接字、建立連線，等價於下面兩行虛擬碼：

<描述符> = socket(<使用IPv4>, <使用TCP>, ...);
connect(<描述符>, <伺服器IP地址和埠號>, ...);

注意：
文中會出現多個關於*ocket的術語，比如Socket庫，就是作業系統提供的庫函式；socket元件就是Socket庫中和socket相關的程式的統稱；socket()函式以及socket（或稱：套接字）就是接下來要講的內容，我會盡量在描述過程中不產生混淆，大家注意根據上下文進行辨析。

3.1.1 何為socket？

上文已經說了，邏輯管道存在的前提是需要各自先建立socket（就好比你打電話之前得先有手機），然後將兩個socket進行關聯。客戶端建立socket非常簡單，只需要呼叫Socket庫中的socket元件的socket()函式就可以了。

<描述符> = socket(<使用IPv4>, <使用TCP>, ...);

客戶端程式碼呼叫socket()函式向協議棧申請建立socket，協議棧會根據你的引數來決定socket是IPv4還是IPv6，是TCP還是UDP。除此之外呢？

基本的髒活累活都是協議棧完成的，協議棧想傳遞訊息總得知道目的IP和埠吧，要是你用的是TCP協議，你甚至還得記錄每個包的傳送時間以及每個包是否收到回覆，否則TCP的超時重傳就不會正常工作。。。等等。。。

因此，協議棧會申請一塊記憶體空間，在其中存放諸如此類的各種控制資訊，協議棧就是根據這些控制資訊來工作的，這些控制資訊我們就可以理解為是socket的實體。怎麼樣，是不是之前感覺虛無縹緲的socket突然鮮活了起來？

我們看一個更鮮活的例子，我在本級上執行netstat -anop命令，得到的每一行資訊我們就可以理解為是一個socket，我們重點看一下下圖中標註的兩條。

這兩條都是redis-server的socket資訊，第1條表示redis-server服務正在IP為127.0.0.1，埠為6379的主機上等待遠端客戶端連線，因為Foreign address為0.0.0.0:*，表示通訊還未開始，IP無法確定，因此State為LISTEN狀態；第2條表示redis-server服務已經建立了與IP為127.0.0.1的客戶端之間的連線，且客戶端使用49968的埠號，目前該socket的狀態為ESTABLISHED。

協議棧建立完socket之後，會返回一個描述符給應用程式。描述符用來識別不同的socket，可以將描述符理解成某個socket的編號，就好比你去洗澡的時候，前臺會發給你一個手牌，原理差不多。

之後對socket進行的任何操作，只要我們出示自己的手牌，啊呸，描述符，協議棧就能知道我們想透過哪個socket進行資料收發了。

至於為什麼不直接返回socket的記憶體地址以及其他細節，可以參考我之前寫的文章《2>&1到底是什麼意思》

3.1.2 何為連線？

connect(<描述符>, <伺服器IP地址和埠號>, ...);

socket剛建立的時候，裡邊沒啥有用的資訊，別說自己即將通訊的物件長啥樣了，就是叫啥，現在在哪兒也不知道，更別提協議棧，自然是啥也知道！

因此，第1件事情就是應用程式需要把伺服器的IP地址和埠號告訴協議棧，有了街道和門牌號，接下來協議棧就可以去找伺服器了。

對於伺服器也是一樣的情況，伺服器也有自己的socket，在接收到客戶端的資訊的同時，伺服器也得知道客戶端的IP和埠號啊，要不然只能單線聯絡了。因此對客戶端做的第1件事情就有了要求，必須把客戶端自己的IP以及埠號告知伺服器，然後兩者就可以愉快的聊天了。

這就是3次握手。

一句話概括連線的含義：連線實際上是通訊的雙方交換控制資訊，並將必要的控制資訊儲存在各自的socket中的過程。

連線過後，每個socket就被4個資訊唯一標識，通常我們稱為四元組：

趁熱打鐵，我們趕緊再說一說伺服器端建立socket以及接受連線的過程。

3.2 服務端的socket流程

public class BIOServerSocket {
    public static void main(String[] args) {
        ServerSocket serverSocket = null;

        try {
            serverSocket = new ServerSocket(8099);
            System.out.println("啟動服務：監聽埠:8099");
            // 等待客戶端的連線過來,如果沒有連線過來，就會阻塞
            while (true) {
                // 表示阻塞等待監聽一個客戶端連線,返回的socket表示連線的客戶端資訊
                Socket socket = serverSocket.accept(); 
                System.out.println("客戶端：" + socket.getPort());
                // 表示獲取客戶端的請求報文
                BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
                // 讀操作也是阻塞的
                String clientStr = bufferedReader.readLine();
                System.out.println("收到客戶端傳送的訊息：" + clientStr);

                BufferedWriter bufferedWriter = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
                bufferedWriter.write("ok\n");
                bufferedWriter.flush();
            }
        } catch (IOException e) {
            // 錯誤處理
        } finally {
            // 其他處理
        }
    }
}

上面一段是非常簡單的Java BIO的服務端程式碼，程式碼的含義就是：

建立socket；
將socket設定為等待連線狀態；
接受客戶端連線；
收發資料。

這些步驟呼叫的底層程式碼的虛擬碼如下：

// 建立socket
<Server描述符> = socket(<使用IPv4>, <使用TCP>, ...);
// 繫結埠號
bind(<Server描述符>, <埠號等>, ...);
// 設定socket為等待連線狀態
listen(<Server描述符>, ...);
// 接受客戶端連線
<新描述符> = accept(<Server描述符>, ...);
// 從客戶端連線中讀取資料
<讀取的資料長度> = read(<新描述符>, <接受緩衝區>, <緩衝區長度>);
// 向客戶端連線中寫資料
write(<新描述符>, <傳送的資料>, <傳送的資料長度>);

3.2.1 建立socket

建立socket這一步和客戶端沒啥區別，不同的是這個socket我們稱之為等待連線socket（或監聽socket）。

3.2.2 繫結埠號

bind()函式會將埠號寫入上一步生成的監聽socket中，這樣一來，監聽socket就完整儲存了服務端的IP和埠號。

3.2.3 listen()的真正作用

listen(<Server描述符>, <最大連線數>);

很多小夥伴一定會對這個listen()有疑問，監聽socket都已經建立完了，埠也已經繫結完了，為什麼還要多呼叫一個listen()呢？

我們剛說過監聽socket和客戶端建立的socket沒什麼區別，問題就出在這個沒什麼區別上。

socket被建立出來的時候都預設是一個主動socket，也就說，核心會認為這個socket之後某個時候會呼叫connect()主動向別的裝置發起連線。這個預設對客戶端socket來說很合理，但是監聽socket可不行，它只能等著客戶端連線自己，因此我們需要呼叫listen()將監聽socket從主動設定為被動，明確告訴核心：你要接受指向這個監聽socket的連線請求！

此外，listen()的第2個引數也大有來頭！監聽socket真正接受的應該是已經完整完成3次握手的客戶端，那麼還沒完成的怎麼辦？總得找個地方放著吧。於是核心為每一個監聽socket都維護了兩個佇列：

半連線佇列（未完成連線的佇列）

這裡存放著暫未徹底完成3次握手的socket（為了防止半連線攻擊，這裡存放的其實是佔用記憶體極小的request _sock，但是我們直接理解成socket就行了），這些socket的狀態稱為SYN_RCVD。