首頁 > 軟體

Redis請求處理的流程分析

2022-07-25 18:06:24

本文使用的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

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

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

http://remcarpediem.net/article/1aa2da89/

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

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

到此這篇關於Redis 是如何進行請求處理的文章就介紹到這了,更多相關Redis請求處理內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!


IT145.com E-mail:sddin#qq.com