一、概述

眾所周知，Redis是一個高性能的數(shù)據(jù)存儲框架，在高并發(fā)的系統(tǒng)設計中，Redis也是一個比較關鍵的組件，是我們提升系統(tǒng)性能的一大利器。深入去理解Redis高性能的原理顯得越發(fā)重要，當然Redis的高性能設計是一個系統(tǒng)性的工程，涉及到很多內容，本文重點關注Redis的IO模型，以及基于IO模型的線程模型。

我們從IO的起源開始，講述了阻塞IO、非阻塞IO、多路復用IO。基于多路復用IO，我們也梳理了幾種不同的Reactor模型，并分析了幾種Reactor模型的優(yōu)缺點。基于Reactor模型我們開始了Redis的IO模型和線程模型的分析，并總結出Redis線程模型的優(yōu)點、缺點，以及后續(xù)的Redis多線程模型方案。本文的重點是對Redis線程模型設計思想的梳理，捋順了設計思想，就是一通百通的事了。

注：本文的代碼都是偽代碼，主要是為了示意，不可用于生產環(huán)境。

二、網(wǎng)絡IO模型發(fā)展史

我們常說的網(wǎng)絡IO模型，主要包含阻塞IO、非阻塞IO、多路復用IO、信號驅動IO、異步IO，本文重點關注跟Redis相關的內容，所以我們重點分析阻塞IO、非阻塞IO、多路復用IO，幫助大家后續(xù)更好的理解Redis網(wǎng)絡模型。

我們先看下面這張圖；

2.1 阻塞IO

我們經常說的阻塞IO其實分為兩種，一種是單線程阻塞，一種是多線程阻塞。這里面其實有兩個概念，阻塞和線程。

• 阻塞：指調用結果返回之前，當前線程會被掛起，調用線程只有在得到結果之后才會返回；
• 線程：系統(tǒng)調用的線程個數(shù)。

像建立連接、讀、寫都涉及到系統(tǒng)調用，本身是一個阻塞的操作。

2.1.1 單線程阻塞

服務端單線程來處理，當客戶端請求來臨時，服務端用主線程來處理連接、讀取、寫入等操作。

以下用代碼模擬了單線程的阻塞模式；

import java.net.Socket;
 
public class BioTest {
 
    public static void main(String[] args) throws IOException {
        ServerSocket server=new ServerSocket(8081);
        while(true) {
            Socket socket=server.accept();
            System.out.println("accept port:"+socket.getPort());
            BufferedReader  in=new BufferedReader(new InputStreamReader(socket.getInputStream()));
            String inData=null;
            try {
                while ((inData = in.readLine()) != null) {
                    System.out.println("client port:"+socket.getPort());
                    System.out.println("input data:"+inData);
                    if("close".equals(inData)) {
                        socket.close();
                    }
                }
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                try {
                    socket.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }      
        }
    }
}

我們準備用兩個客戶端同時發(fā)起連接請求、來模擬單線程阻塞模式的現(xiàn)象。同時發(fā)起連接，通過服務端日志，我們發(fā)現(xiàn)此時服務端只接受了其中一個連接，主線程被阻塞在上一個連接的read方法上。

我們嘗試關閉第一個連接，看第二個連接的情況，我們希望看到的現(xiàn)象是，主線程返回，新的客戶端連接被接受。

從日志中發(fā)現(xiàn)，在第一個連接被關閉后，第二個連接的請求被處理了，也就是說第二個連接請求在排隊，直到主線程被喚醒，才能接收下一個請求，符合我們的預期。

此時不僅要問，為什么呢？

主要原因在于accept、read、write三個函數(shù)都是阻塞的，主線程在系統(tǒng)調用的時候，線程是被阻塞的，其他客戶端的連接無法被響應。

通過以上流程，我們很容易發(fā)現(xiàn)這個過程的缺陷，服務器每次只能處理一個連接請求，CPU沒有得到充分利用，性能比較低。如何充分利用CPU的多核特性呢？自然而然的想到了——多線程邏輯。

2.1.2 多線程阻塞

對工程師而言，代碼解釋一切，直接上代碼。

BIO多線程

package net.io.bio;
 
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.ServerSocket;
import java.net.Socket;
 
public class BioTest {
 
    public static void main(String[] args) throws IOException {
        final ServerSocket server=new ServerSocket(8081);
        while(true) {
            new Thread(new Runnable() {
                public void run() {
                    Socket socket=null;
                    try {
                        socket = server.accept();
                        System.out.println("accept port:"+socket.getPort());
                        BufferedReader  in=new BufferedReader(new InputStreamReader(socket.getInputStream()));
                        String inData=null;
                        while ((inData = in.readLine()) != null) {
                            System.out.println("client port:"+socket.getPort());
                            System.out.println("input data:"+inData);
                            if("close".equals(inData)) {
                                socket.close();
                            }
                        }
                    } catch (IOException e) {
                        e.printStackTrace();
                    } finally {
                         
                    }
                }
            }).start();
        }
    }
 
}

同樣，我們并行發(fā)起兩個請求；

兩個請求，都被接受，服務端新增兩個線程來處理客戶端的連接和后續(xù)請求。

我們用多線程解決了，服務器同時只能處理一個請求的問題，但同時又帶來了一個問題，如果客戶端連接比較多時，服務端會創(chuàng)建大量的線程來處理請求，但線程本身是比較耗資源的，創(chuàng)建、上下文切換都比較耗資源，又如何去解決呢？

2.2 非阻塞

如果我們把所有的Socket（文件句柄，后續(xù)用Socket來代替fd的概念，盡量減少概念，減輕閱讀負擔）都放到隊列里，只用一個線程來輪訓所有的Socket的狀態(tài)，如果準備好了就把它拿出來，是不是就減少了服務端的線程數(shù)呢？

一起看下代碼，單純非阻塞模式，我們基本上不用，為了演示邏輯，我們模擬了相關代碼如下；

package net.io.bio;
 
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.SocketTimeoutException;
import java.util.ArrayList;
import java.util.List;
 
import org.apache.commons.collections4.CollectionUtils;
 
 
public class NioTest {
 
    public static void main(String[] args) throws IOException {
        final ServerSocket server=new ServerSocket(8082);
        server.setSoTimeout(1000);
        List<Socket> sockets=new ArrayList<Socket>();
        while (true) {
            Socket socket = null;
            try {
                socket = server.accept();
                socket.setSoTimeout(500);
                sockets.add(socket);
                System.out.println("accept client port:"+socket.getPort());
            } catch (SocketTimeoutException e) {
                System.out.println("accept timeout");
            }
            //模擬非阻塞：輪詢已連接的socket，每個socket等待10MS，有數(shù)據(jù)就處理，無數(shù)據(jù)就返回，繼續(xù)輪詢
            if(CollectionUtils.isNotEmpty(sockets)) {
                for(Socket socketTemp:sockets ) {
                    try {
                        BufferedReader  in=new BufferedReader(new InputStreamReader(socketTemp.getInputStream()));
                        String inData=null;
                        while ((inData = in.readLine()) != null) {
                            System.out.println("input data client port:"+socketTemp.getPort());
                            System.out.println("input data client port:"+socketTemp.getPort() +"data:"+inData);
                            if("close".equals(inData)) {
                                socketTemp.close();
                            }
                        }
                    } catch (SocketTimeoutException e) {
                        System.out.println("input client loop"+socketTemp.getPort());
                    }
                }
            }
        }
 
    }
}

系統(tǒng)初始化，等待連接；

發(fā)起兩個客戶端連接，線程開始輪詢兩個連接中是否有數(shù)據(jù)。

兩個連接分別輸入數(shù)據(jù)后，輪詢線程發(fā)現(xiàn)有數(shù)據(jù)準備好了，開始相關的邏輯處理（單線程、多線程都可）。

再用一張流程圖輔助解釋下（系統(tǒng)實際采用文件句柄，此時用Socket來代替，方便大家理解）。

服務端專門有一個線程來負責輪詢所有的Socket，來確認操作系統(tǒng)是否完成了相關事件，如果有則返回處理，如果無繼續(xù)輪詢，大家一起來思考下？此時又帶來了什么問題呢。

CPU的空轉、系統(tǒng)調用（每次輪詢到涉及到一次系統(tǒng)調用，通過內核命令來確認數(shù)據(jù)是否準備好），造成資源的浪費，那有沒有一種機制，來解決這個問題呢？

2.3 IO多路復用

server端有沒專門的線程來做輪詢操作（應用程序端非內核），而是由事件來觸發(fā)，當有相關讀、寫、連接事件到來時，主動喚起服務端線程來進行相關邏輯處理。模擬了相關代碼如下；

IO多路復用

import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.nio.charset.Charset;
import java.util.Iterator;
import java.util.Set;
 
public class NioServer {
 
    private static  Charset charset = Charset.forName("UTF-8");
    public static void main(String[] args) {
        try {
            Selector selector = Selector.open();
            ServerSocketChannel chanel = ServerSocketChannel.open();
            chanel.bind(new InetSocketAddress(8083));
            chanel.configureBlocking(false);
            chanel.register(selector, SelectionKey.OP_ACCEPT);
 
            while (true){
                int select = selector.select();
                if(select == 0){
                    System.out.println("select loop");
                    continue;
                }
                System.out.println("os data ok");
                 
                Set<SelectionKey> selectionKeys = selector.selectedKeys();
                Iterator<SelectionKey> iterator = selectionKeys.iterator();
                while (iterator.hasNext()){
                    SelectionKey selectionKey = iterator.next();
                     
                    if(selectionKey.isAcceptable()){
                        ServerSocketChannel server = (ServerSocketChannel)selectionKey.channel();
                        SocketChannel client = server.accept();
                        client.configureBlocking(false);
                        client.register(selector, SelectionKey.OP_READ);
                        //繼續(xù)可以接收連接事件
                        selectionKey.interestOps(SelectionKey.OP_ACCEPT);
                    }else if(selectionKey.isReadable()){
                        //得到SocketChannel
                        SocketChannel client = (SocketChannel)selectionKey.channel();
                        //定義緩沖區(qū)
                        ByteBuffer buffer = ByteBuffer.allocate(1024);
                        StringBuilder content = new StringBuilder();
                        while (client.read(buffer) > 0){
                            buffer.flip();
                            content.append(charset.decode(buffer));
                        }
                        System.out.println("client port:"+client.getRemoteAddress().toString()+",input data: "+content.toString());
                        //清空緩沖區(qū)
                        buffer.clear();
                    }
                    iterator.remove();
                }
            }
 
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

同時創(chuàng)建兩個連接；

兩個連接無阻塞的被創(chuàng)建；

無阻塞的接收讀寫；

再用一張流程圖輔助解釋下（系統(tǒng)實際采用文件句柄，此時用Socket來代替，方便大家理解）。

當然操作系統(tǒng)的多路復用有好幾種實現(xiàn)方式，我們經常使用的select()，epoll模式這里不做過多的解釋，有興趣的可以查看相關文檔，IO的發(fā)展后面還有異步、事件等模式，我們在這里不過多的贅述，我們更多的是為了解釋Redis線程模式的發(fā)展。

三、NIO線程模型解釋

我們一起來聊了阻塞、非阻塞、IO多路復用模式，那Redis采用的是哪種呢？

Redis采用的是IO多路復用模式，所以我們重點來了解下多路復用這種模式，如何在更好的落地到我們系統(tǒng)中，不可避免的我們要聊下Reactor模式。

首先我們做下相關的名詞解釋；

Reactor：類似NIO編程中的Selector，負責I/O事件的派發(fā)；

Acceptor：NIO中接收到事件后，處理連接的那個分支邏輯；

Handler：消息讀寫處理等操作類。

3.1 單Reactor單線程模型

處理流程

• Reactor監(jiān)聽連接事件、Socket事件，當有連接事件過來時交給Acceptor處理，當有Socket事件過來時交個對應的Handler處理。

優(yōu)點

• 模型比較簡單，所有的處理過程都在一個連接里；
• 實現(xiàn)上比較容易，模塊功能也比較解耦，Reactor負責多路復用和事件分發(fā)處理，Acceptor負責連接事件處理，Handler負責Scoket讀寫事件處理。

缺點

• 只有一個線程，連接處理和業(yè)務處理共用一個線程，無法充分利用CPU多核的優(yōu)勢。
• 在流量不是特別大、業(yè)務處理比較快的時候系統(tǒng)可以有很好的表現(xiàn)，當流量比較大、讀寫事件比較耗時情況下，容易導致系統(tǒng)出現(xiàn)性能瓶頸。

怎么去解決上述問題呢？既然業(yè)務處理邏輯可能會影響系統(tǒng)瓶頸，那我們是不是可以把業(yè)務處理邏輯單拎出來，交給線程池來處理，一方面減小對主線程的影響，另一方面利用CPU多核的優(yōu)勢。這一點希望大家要理解透徹，方便我們后續(xù)理解Redis由單線程模型到多線程模型的設計的思路。

3.2 單Reactor多線程模型

這種模型相對單Reactor單線程模型，只是將業(yè)務邏輯的處理邏輯交給了一個線程池來處理。

處理流程

• Reactor監(jiān)聽連接事件、Socket事件，當有連接事件過來時交給Acceptor處理，當有Socket事件過來時交個對應的Handler處理。
• Handler完成讀事件后，包裝成一個任務對象，交給線程池來處理，把業(yè)務處理邏輯交給其他線程來處理。

優(yōu)點

• 讓主線程專注于通用事件的處理（連接、讀、寫），從設計上進一步解耦；
• 利用CPU多核的優(yōu)勢。

缺點

• 貌似這種模型已經很完美了，我們再思考下，如果客戶端很多、流量特別大的時候，通用事件的處理（讀、寫）也可能會成為主線程的瓶頸，因為每次讀、寫操作都涉及系統(tǒng)調用。

有沒有什么好的辦法來解決上述問題呢？通過以上的分析，大家有沒有發(fā)現(xiàn)一個現(xiàn)象，當某一個點成為系統(tǒng)瓶頸點時，想辦法把他拿出來，交個其他線程來處理，那這種場景是否適用呢？

3.3 多Reactor多線程模型

這種模型相對單Reactor多線程模型，只是將Scoket的讀寫處理從mainReactor中拎出來，交給subReactor線程來處理。

處理流程

• mainReactor主線程負責連接事件的監(jiān)聽和處理，當Acceptor處理完連接過程后，主線程將連接分配給subReactor；
• subReactor負責mainReactor分配過來的Socket的監(jiān)聽和處理，當有Socket事件過來時交個對應的Handler處理；

Handler完成讀事件后，包裝成一個任務對象，交給線程池來處理，把業(yè)務處理邏輯交給其他線程來處理。

優(yōu)點

• 讓主線程專注于連接事件的處理，子線程專注于讀寫事件吹，從設計上進一步解耦；
• 利用CPU多核的優(yōu)勢。

缺點

• 實現(xiàn)上會比較復雜，在極度追求單機性能的場景中可以考慮使用。

四、Redis的線程模型

4.1 概述

以上我們聊了，IO網(wǎng)路模型的發(fā)展歷史，也聊了IO多路復用的reactor模式。那Redis采用的是哪種reactor模式呢？在回答這個問題前，我們先梳理幾個概念性的問題。

Redis服務器中有兩類事件，文件事件和時間事件。

• 文件事件：在這里可以把文件理解為Socket相關的事件，比如連接、讀、寫等；
• 時間時間：可以理解為定時任務事件，比如一些定期的RDB持久化操作。

本文重點聊下Socket相關的事件。

4.2 模型圖

首先我們來看下Redis服務的線程模型圖；

IO多路復用負責各事件的監(jiān)聽（連接、讀、寫等），當有事件發(fā)生時，將對應事件放入隊列中，由事件分發(fā)器根據(jù)事件類型來進行分發(fā)；

如果是連接事件，則分發(fā)至連接應答處理器；GET、SET等redis命令分發(fā)至命令請求處理器。

命令處理完后產生命令回復事件，再由事件隊列，到事件分發(fā)器，到命令回復處理器，回復客戶端響應。

4.3 一次客戶端和服務端的交互流程

4.3.1 連接流程

連接過程

• Redis服務端主線程監(jiān)聽固定端口，并將連接事件綁定連接應答處理器。
• 客戶端發(fā)起連接后，連接事件被觸發(fā)，IO多路復用程序將連接事件包裝好后丟人事件隊列，然后由事件分發(fā)處理器分發(fā)給連接應答處理器。
• 連接應答處理器創(chuàng)建client對象以及Socket對象，我們這里關注Socket對象，并產生ae_readable事件，和命令處理器關聯(lián)，標識后續(xù)該Socket對可讀事件感興趣，也就是開始接收客戶端的命令操作。
• 當前過程都是由一個主線程負責處理。

4.3.2 命令執(zhí)行流程

SET命令執(zhí)行過程

• 客戶端發(fā)起SET命令，IO多路復用程序監(jiān)聽到該事件后（讀事件），將數(shù)據(jù)包裝成事件丟到事件隊列中（事件在上個流程中綁定了命令請求處理器）；
• 事件分發(fā)處理器根據(jù)事件類型，將事件分發(fā)給對應的命令請求處理器；
• 命令請求處理器，讀取Socket中的數(shù)據(jù)，執(zhí)行命令，然后產生ae_writable事件，并綁定命令回復處理器；
• IO多路復用程序監(jiān)聽到寫事件后，將數(shù)據(jù)包裝成事件丟到事件隊列中，事件分發(fā)處理器根據(jù)事件類型分發(fā)至命令回復處理器；
• 命令回復處理器，將數(shù)據(jù)寫入Socket中返回給客戶端。

4.4 模型優(yōu)缺點

以上流程分析我們可以看出Redis采用的是單線程Reactor模型，我們也分析了這種模式的優(yōu)缺點，那Redis為什么還要采用這種模式呢？

Redis本身的特性

命令執(zhí)行基于內存操作，業(yè)務處理邏輯比較快，所以命令處理這一塊單線程來做也能維持一個很高的性能。

優(yōu)點

• Reactor單線程模型的優(yōu)點，參考上文。

缺點

• Reactor單線程模型的缺點也同樣在Redis中來體現(xiàn)，唯一不同的地方就在于業(yè)務邏輯處理（命令執(zhí)行）這塊不是系統(tǒng)瓶頸點。
• 隨著流量的上漲，IO操作的的耗時會越來越明顯（read操作，內核中讀數(shù)據(jù)到應用程序。write操作，應用程序中的數(shù)據(jù)到內核），當達到一定閥值時系統(tǒng)的瓶頸就體現(xiàn)出來了。

Redis又是如何去解的呢？

哈哈~將耗時的點從主線程拎出來唄？那Redis的新版本是這么做的嗎？我們一起來看下。

4.5 Redis多線程模式

Redis的多線程模型跟”多Reactor多線程模型“、“單Reactor多線程模型有點區(qū)別”，但同時用了兩種Reactor模型的思想，具體如下；

• Redis的多線程模型是將IO操作多線程化，本身邏輯處理過程（命令執(zhí)行過程）依舊是單線程，借助了單Reactor思想，實現(xiàn)上又有所區(qū)分。
• 將IO操作多線程化，又跟單Reactor衍生出多Reactor的思想一致，都是將IO操作從主線程中拎出來。

命令執(zhí)行大致流程

• 客戶端發(fā)送請求命令，觸發(fā)讀就緒事件，服務端主線程將Socket（為了簡化理解成本，統(tǒng)一用Socket來代表連接）放入一個隊列，主線程不負責讀；
• IO 線程通過Socket讀取客戶端的請求命令，主線程忙輪詢，等待所有 I/O 線程完成讀取任務，IO線程只負責讀不負責執(zhí)行命令；
• 主線程一次性執(zhí)行所有命令，執(zhí)行過程和單線程一樣，然后需要返回的連接放入另外一個隊列中，有IO線程來負責寫出（主線程也會寫）；
• 主線程忙輪詢，等待所有 I/O 線程完成寫出任務。

五、總結

了解一個組件，更多的是要去了解他的設計思路，要去思考為什么要這么設計，做這種技術選型的背景是啥，對后續(xù)做系統(tǒng)架構設計有什么參考意義等等。一通百通，希望對大家有參考意義。

到此這篇關于Redis線程模型的原理分析的文章就介紹到這了,更多相關Redis線程模型內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論