Redis請求處理的流程分析
本文使用的Redis 5.0源碼
感覺這部分的代碼還是挺有意思的,我盡量用比較通俗的方式進行講解
概述#
我記得我在 一文說透 Go 語言 HTTP 標準庫 這篇文章里面解析了對于 Go 來說是如何創(chuàng)建一個 Server 端程序的:
- 首先是注冊處理器;
- 開啟循環(huán)監(jiān)聽端口,每監(jiān)聽到一個連接就會創(chuàng)建一個 Goroutine;
- 然后就是 Goroutine 里面會循環(huán)的等待接收請求數(shù)據(jù),然后根據(jù)請求的地址去處理器路由表中匹配對應(yīng)的處理器,然后將請求交給處理器處理;
用代碼表示就是這樣:
func (srv *Server) Serve(l net.Listener) error { ... baseCtx := context.Background() ctx := context.WithValue(baseCtx, ServerContextKey, srv) for { // 接收 listener 過來的網(wǎng)絡(luò)連接 rw, err := l.Accept() ... tempDelay = 0 c := srv.newConn(rw) c.setState(c.rwc, StateNew) // 創(chuàng)建協(xié)程處理連接 go c.serve(connCtx) } }
對于 Redis 來說就有些不太一樣,因為它是單線程的,無法使用多線程處理連接,所以 Redis 選擇使用基于 Reactor 模式的事件驅(qū)動程序來實現(xiàn)事件的并發(fā)處理。
在 Redis 中所謂 Reactor 模式就是通過 epoll 來監(jiān)聽多個 fd,每當這些 fd 有響應(yīng)的時候會以事件的形式通知 epoll 進行回調(diào),每一個事件都有一個對應(yīng)的事件處理器。
如: accept 對應(yīng) acceptTCPHandler 事件處理器、read & write 對應(yīng)readQueryFromClient 事件處理器等,然后通過事件的循環(huán)派發(fā)的形式將事件分配給事件處理器進行處理。
所以說上面的這個 Reactor 模式都是通過 epoll 來實現(xiàn)的,對于 epoll 來說主要有這三個方法:
//創(chuàng)建一個epoll的句柄,size用來告訴內(nèi)核這個監(jiān)聽的數(shù)目一共有多大 int epoll_create(int size); /* * 可以理解為,增刪改 fd 需要監(jiān)聽的事件 * epfd 是 epoll_create() 創(chuàng)建的句柄。 * op 表示 增刪改 * epoll_event 表示需要監(jiān)聽的事件,Redis 只用到了可讀,可寫,錯誤,掛斷 四個狀態(tài) */ int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); /* * 可以理解為查詢符合條件的事件 * epfd 是 epoll_create() 創(chuàng)建的句柄。 * epoll_event 用來存放從內(nèi)核得到事件的集合 * maxevents 獲取的最大事件數(shù) * timeout 等待超時時間 */ int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
所以我們可以根據(jù)這三個方法實現(xiàn)一個簡單的 server:
// 創(chuàng)建監(jiān)聽 int listenfd = ::socket(); // 綁定ip和端口 int r = ::bind(); // 創(chuàng)建 epoll 實例 int epollfd = epoll_create(xxx); // 添加epoll要監(jiān)聽的事件類型 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; // 進行事件的分發(fā) if ( (events & EPOLLERR) || (events & EPOLLHUP) ) { ... } else if (events & EPOLLRDHUP) { ... } ... } }
調(diào)用流程#
所以根據(jù)上面的介紹,可以知道對于 Redis 來說一個事件循環(huán)無非也就這么幾步:
- 注冊事件監(jiān)聽及回調(diào)函數(shù);
- 循環(huán)等待獲取事件并處理;
- 調(diào)用回調(diào)函數(shù),處理數(shù)據(jù)邏輯;
- 回寫數(shù)據(jù)給 Client;
- 注冊 fd 到 epoll 中,并設(shè)置回調(diào)函數(shù) acceptTcpHandler,如果有新連接那么會調(diào)用回調(diào)函數(shù);
- 啟動一個死循環(huán)調(diào)用 epoll_wait 等待并持續(xù)處理事件,待會我們回到 aeMain 函數(shù)中循環(huán)調(diào) aeProcessEvents 函數(shù);
- 當有網(wǎng)絡(luò)事件過來的時候,會順著回調(diào)函數(shù) acceptTcpHandler 一路調(diào)用到 readQueryFromClient 進行數(shù)據(jù)的處理,readQueryFromClient 會解析 client 的數(shù)據(jù),找到對應(yīng)的 cmd 函數(shù)執(zhí)行;
- Redis 實例在收到客戶端請求后,會在處理客戶端命令后,將要返回的數(shù)據(jù)寫入客戶端輸出緩沖區(qū)中而不是立馬返回;
- 然后在 aeMain 函數(shù)每次循環(huán)時都會調(diào)用 beforeSleep 函數(shù)將緩沖區(qū)中的數(shù)據(jù)寫回客戶端;
上面的整個事件循環(huán)的過程實際上代碼步驟已經(jīng)寫的非常清晰,網(wǎng)上也有很多文章介紹,我就不多講了。
命令執(zhí)行過程 & 回寫客戶端#
命令執(zhí)行#
下面我們講點網(wǎng)上很多文章都沒提及的,看看 Redis 是如何執(zhí)行命令,然后存入緩存,以及將數(shù)據(jù)從緩存寫回 Client 這個過程。
在前一節(jié)我們也提到了,如果有網(wǎng)絡(luò)事件過來的時候會調(diào)用到 readQueryFromClient 函數(shù),它是真正執(zhí)行命令的地方。我們也就順著這個方法一直往下看:
- readQueryFromClient 里面會調(diào)用 processInputBufferAndReplicate 函數(shù)處理請求的命令;
- 在 processInputBufferAndReplicate 函數(shù)里面會調(diào)用 processInputBuffer 以及判斷一下如果是集群模式的話,是否需要將命令復(fù)制給其他節(jié)點;
- processInputBuffer 函數(shù)里面會循環(huán)處理請求的命令,并根據(jù)請求的協(xié)議調(diào)用 processInlineBuffer 函數(shù),將 redisObject 對象后調(diào)用 processCommand 執(zhí)行命令;
- processCommand 在執(zhí)行命令的時候會通過 lookupCommand 去
server.commands
表中根據(jù)命令查找對應(yīng)的執(zhí)行函數(shù),然后經(jīng)過一系列的校驗之后,調(diào)用相應(yīng)的函數(shù)執(zhí)行命令,調(diào)用 addReply 將要返回的數(shù)據(jù)寫入客戶端輸出緩沖區(qū);
server.commands
會在 populateCommandTable 函數(shù)中將所有的 Redis 命令注冊進去,作為一個根據(jù)命令名獲取命令函數(shù)的表。
比如說,要執(zhí)行 get 命令,那么會調(diào)用到 getCommand 函數(shù):
void getCommand(client *c) { getGenericCommand(c); } int getGenericCommand(client *c) { robj *o; // 查找數(shù)據(jù) if ((o = lookupKeyReadOrReply(c,c->argv[1],shared.nullbulk)) == NULL) return C_OK; ... } robj *lookupKeyReadOrReply(client *c, robj *key, robj *reply) { //到db中查找數(shù)據(jù) robj *o = lookupKeyRead(c->db, key); // 寫入到緩存中 if (!o) addReply(c,reply); return o; }
在 getCommand 函數(shù)中查找到數(shù)據(jù),然后調(diào)用 addReply 將要返回的數(shù)據(jù)寫入客戶端輸出緩沖區(qū)。
數(shù)據(jù)回寫客戶端#
在上面執(zhí)行完命令寫入到緩沖區(qū)后,還需要從緩沖區(qū)取出數(shù)據(jù)返回給 Client。對于數(shù)據(jù)回寫客戶端這個流程來說,其實也是在服務(wù)端的事件循環(huán)中完成的。
- 首先 Redis 會在 main 函數(shù)中調(diào)用 aeSetBeforeSleepProc 函數(shù)將回寫包的函數(shù) beforeSleep 注冊到 eventLoop 中去;
- 然后 Redis 在調(diào)用 aeMain 函數(shù)進行事件循環(huán)的時候都會判斷一下 beforesleep 有沒有被設(shè)值,如果有,那么就會進行調(diào)用;
- beforesleep 函數(shù)里面會調(diào)用到 handleClientsWithPendingWrites 函數(shù),它會調(diào)用 writeToClient 將數(shù)據(jù)從緩沖區(qū)中回寫給客戶端;
總結(jié)#
這篇文章介紹了整個 Redis 的請求處理模型到底是怎樣的。從注冊監(jiān)聽 fd 事件到執(zhí)行命令,到最后將數(shù)據(jù)回寫給客戶端都做了個大概的分析。當然這篇文章也和我以往的文章有點不同,沒有長篇大論的貼代碼,主要我覺得也沒啥必要,感興趣可以順著流程圖去看看代碼。
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
到此這篇關(guān)于Redis 是如何進行請求處理的文章就介紹到這了,更多相關(guān)Redis請求處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis?的內(nèi)存淘汰策略和過期刪除策略的區(qū)別
這篇文章主要介紹了Redis?的內(nèi)存淘汰策略和過期刪除策略的區(qū)別,Redis?是可以對?key?設(shè)置過期時間的,因此需要有相應(yīng)的機制將已過期的鍵值對刪除,而做這個工作的就是過期鍵值刪除策略2022-07-07SpringBoot整合Redis入門之緩存數(shù)據(jù)的方法
Redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫,并提供多種語言的API,下面通過本文給大家介紹下SpringBoot整合Redis入門之緩存數(shù)據(jù)的相關(guān)知識,感興趣的朋友一起看看吧2021-11-11使用lua+redis解決發(fā)多張券的并發(fā)問題
這篇文章主要介紹了使用lua+redis解決發(fā)多張券的并發(fā)問題,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-01-01Window下對Redis進行開啟與關(guān)閉的操作方法
這篇文章主要介紹了Window下對Redis進行開啟與關(guān)閉的操作方法,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-11-11