聊聊 Redis 是如何進行請求處理

2022 年 7 月 24 日
筆記
Redis

轉載請聲明出處哦~，本篇文章發佈於luozhiyun的博客：//www.luozhiyun.com/archives/674

本文使用的Redis 5.0源碼

感覺這部分的代碼還是挺有意思的，我盡量用比較通俗的方式進行講解

概述

我記得我在一文說透 Go 語言 HTTP 標準庫這篇文章裏面解析了對於 Go 來說是如何創建一個 Server 端程序的：

首先是註冊處理器；
開啟循環監聽端口，每監聽到一個連接就會創建一個 Goroutine；
然後就是 Goroutine 裏面會循環的等待接收請求數據，然後根據請求的地址去處理器路由表中匹配對應的處理器，然後將請求交給處理器處理；

用代碼表示就是這樣：

func (srv *Server) Serve(l net.Listener) error { 
    ...
    baseCtx := context.Background()  
    ctx := context.WithValue(baseCtx, ServerContextKey, srv)
    for {
        // 接收 listener 過來的網絡連接
        rw, err := l.Accept()
        ... 
        tempDelay = 0
        c := srv.newConn(rw)
        c.setState(c.rwc, StateNew) 
        // 創建協程處理連接
        go c.serve(connCtx)
    }
}

對於 Redis 來說就有些不太一樣，因為它是單線程的，無法使用多線程處理連接，所以 Redis 選擇使用基於 Reactor 模式的事件驅動程序來實現事件的並發處理。

在 Redis 中所謂 Reactor 模式就是通過 epoll 來監聽多個 fd，每當這些 fd 有響應的時候會以事件的形式通知 epoll 進行回調，每一個事件都有一個對應的事件處理器。

如： accept 對應 acceptTCPHandler 事件處理器、read & write 對應readQueryFromClient 事件處理器等，然後通過事件的循環派發的形式將事件分配給事件處理器進行處理。

所以說上面的這個 Reactor 模式都是通過 epoll 來實現的，對於 epoll 來說主要有這三個方法：

//創建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大
int epoll_create(int size)；

/*
 * 可以理解為，增刪改 fd 需要監聽的事件
 * epfd 是 epoll_create() 創建的句柄。
 * op 表示 增刪改
 * epoll_event 表示需要監聽的事件，Redis 只用到了可讀，可寫，錯誤，掛斷 四個狀態
 */
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；

/*
 * 可以理解為查詢符合條件的事件
 * epfd 是 epoll_create() 創建的句柄。
 * epoll_event 用來存放從內核得到事件的集合
 * maxevents 獲取的最大事件數
 * timeout 等待超時時間
 */
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

所以我們可以根據這三個方法實現一個簡單的 server：

// 創建監聽
int listenfd = ::socket();

// 綁定ip和端口
int r = ::bind();  
// 創建 epoll 實例
int epollfd = epoll_create(xxx); 
// 添加epoll要監聽的事件類型
int r = epoll_ctl(..., listenfd, ...);
 
struct epoll_event* alive_events =  static_cast<epoll_event*>(calloc(kMaxEvents, sizeof(epoll_event)));

while (true) {
    // 等待事件
    int num = epoll_wait(epollfd, alive_events, kMaxEvents, kEpollWaitTime);
	// 遍歷事件，並進行事件處理
    for (int i = 0; i < num; ++i) {
        int fd = alive_events[i].data.fd;
        // 獲取事件
        int events = alive_events[i].events;
		// 進行事件的分發
        if ( (events & EPOLLERR) || (events & EPOLLHUP) ) {
            ...
        } else  if (events & EPOLLRDHUP) {
            ...
        } 
        ...
    }   
}

調用流程

所以根據上面的介紹，可以知道對於 Redis 來說一個事件循環無非也就這麼幾步：

註冊事件監聽及回調函數；
循環等待獲取事件並處理；
調用回調函數，處理數據邏輯；
回寫數據給 Client；

註冊 fd 到 epoll 中，並設置回調函數 acceptTcpHandler，如果有新連接那麼會調用回調函數；
啟動一個死循環調用 epoll_wait 等待並持續處理事件，待會我們回到 aeMain 函數中循環調 aeProcessEvents 函數；
當有網絡事件過來的時候，會順着回調函數 acceptTcpHandler 一路調用到 readQueryFromClient 進行數據的處理，readQueryFromClient 會解析 client 的數據，找到對應的 cmd 函數執行；
Redis 實例在收到客戶端請求後，會在處理客戶端命令後，將要返回的數據寫入客戶端輸出緩衝區中而不是立馬返回；
然後在 aeMain 函數每次循環時都會調用 beforeSleep 函數將緩衝區中的數據寫回客戶端；

上面的整個事件循環的過程實際上代碼步驟已經寫的非常清晰，網上也有很多文章介紹，我就不多講了。

命令執行過程 & 回寫客戶端

命令執行

下面我們講點網上很多文章都沒提及的，看看 Redis 是如何執行命令，然後存入緩存，以及將數據從緩存寫回 Client 這個過程。

在前一節我們也提到了，如果有網絡事件過來的時候會調用到 readQueryFromClient 函數，它是真正執行命令的地方。我們也就順着這個方法一直往下看：

readQueryFromClient 裏面會調用 processInputBufferAndReplicate 函數處理請求的命令；
在 processInputBufferAndReplicate 函數裏面會調用 processInputBuffer 以及判斷一下如果是集群模式的話，是否需要將命令複製給其他節點；
processInputBuffer 函數裏面會循環處理請求的命令，並根據請求的協議調用 processInlineBuffer 函數，將 redisObject 對象後調用 processCommand 執行命令；
processCommand 在執行命令的時候會通過 lookupCommand 去 server.commands 表中根據命令查找對應的執行函數，然後經過一系列的校驗之後，調用相應的函數執行命令，調用 addReply 將要返回的數據寫入客戶端輸出緩衝區；

server.commands會在 populateCommandTable 函數中將所有的 Redis 命令註冊進去，作為一個根據命令名獲取命令函數的表。

比如說，要執行 get 命令，那麼會調用到 getCommand 函數：

void getCommand(client *c) {
    getGenericCommand(c);
}

int getGenericCommand(client *c) {
    robj *o;
	// 查找數據
    if ((o = lookupKeyReadOrReply(c,c->argv[1],shared.nullbulk)) == NULL)
        return C_OK;
    ...
}

robj *lookupKeyReadOrReply(client *c, robj *key, robj *reply) {
    //到db中查找數據
    robj *o = lookupKeyRead(c->db, key);
    // 寫入到緩存中
    if (!o) addReply(c,reply);
    return o;
}

在 getCommand 函數中查找到數據，然後調用 addReply 將要返回的數據寫入客戶端輸出緩衝區。

數據回寫客戶端

在上面執行完命令寫入到緩衝區後，還需要從緩衝區取出數據返回給 Client。對於數據回寫客戶端這個流程來說，其實也是在服務端的事件循環中完成的。

首先 Redis 會在 main 函數中調用 aeSetBeforeSleepProc 函數將回寫包的函數 beforeSleep 註冊到 eventLoop 中去；
然後 Redis 在調用 aeMain 函數進行事件循環的時候都會判斷一下 beforesleep 有沒有被設值，如果有，那麼就會進行調用；
beforesleep 函數裏面會調用到 handleClientsWithPendingWrites 函數，它會調用 writeToClient 將數據從緩衝區中回寫給客戶端；

總結

這篇文章介紹了整個 Redis 的請求處理模型到底是怎樣的。從註冊監聽 fd 事件到執行命令，到最後將數據回寫給客戶端都做了個大概的分析。當然這篇文章也和我以往的文章有點不同，沒有長篇大論的貼代碼，主要我覺得也沒啥必要，感興趣可以順着流程圖去看看代碼。

Reference

//www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf

//time.geekbang.org/column/article/408491

//remcarpediem.net/article/1aa2da89/

//github.com/Junnplus/blog/issues/37

//www.cnblogs.com/neooelric/p/9629948.html

Tags: Redis