redis事件處理流程的案例分析

這篇文章主要介紹了redis事件處理流程的案例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

前言：

我們知道redis服務(wù)器是一個(gè)事件驅(qū)動(dòng)程序，它需要處理兩類(lèi)事件，分別是文件事件和時(shí)間事件。

那么redis事件處理流程是什么樣的呢？我們一起來(lái)看看下面的圖：

aeMain函數(shù)通過(guò)調(diào)用aeProcessEvents函數(shù)來(lái)進(jìn)行文件事件和時(shí)間事件的調(diào)度和執(zhí)行。aeEventLoop中記錄了事件相關(guān)的信息。首先通過(guò)aeSearchNearestTimer函數(shù)獲取最短的時(shí)間事件的執(zhí)行時(shí)間間隔n，然后調(diào)用aeApiPoll函數(shù)獲取監(jiān)聽(tīng)到的套接字，最后執(zhí)行與套接字向?qū)?yīng)的事件處理函數(shù)rfileProc和wfileProc，最后再執(zhí)行時(shí)間事件函數(shù)processTimeEvents

文件事件

Redis的基于Reactor模式開(kāi)發(fā)了自己的網(wǎng)絡(luò)事件處理器，這個(gè)處理器被稱為文件事件處理器（file event handler）：

• 文件事件處理器使用IO多路復(fù)用程序來(lái)監(jiān)聽(tīng)多個(gè)套接字，并根據(jù)套接字目前執(zhí)行的任務(wù)為套接字關(guān)聯(lián)不同的事件處理器

• 當(dāng)被監(jiān)聽(tīng)的套接字準(zhǔn)備好執(zhí)行連接應(yīng)答（accept）、讀?。╮ead）、寫(xiě)入（write）、關(guān)閉（close）等操作，當(dāng)文件事件產(chǎn)生時(shí)，這些文件事件處理器就會(huì)調(diào)用套接字之前關(guān)聯(lián)好的事件處理器來(lái)處理事件

文件事件處理器的構(gòu)成

（學(xué)習(xí)視頻分享：redis視頻教程）

文件事件的處理器

Redis為文件事件編寫(xiě)了多個(gè)處理器：

• 連接應(yīng)答處理器：當(dāng)Redis服務(wù)器進(jìn)行初始化是，程序會(huì)將這個(gè)連接應(yīng)答處理器和服務(wù)監(jiān)聽(tīng)套件字的AE_READABLE事件關(guān)聯(lián)起來(lái)，當(dāng)有客戶端用connect函數(shù)連接服務(wù)器監(jiān)聽(tīng)套接字是，套接字就會(huì)產(chǎn)生AE_READABLE事件，引發(fā)連接應(yīng)答處理器執(zhí)行，并執(zhí)行相應(yīng)的套接字應(yīng)答操作

• 命令請(qǐng)求處理器：當(dāng)一個(gè)客戶端通過(guò)連接應(yīng)答處理器成功連接到服務(wù)器之后，服務(wù)器會(huì)將客戶端套接字的AE_READABLE事件和命令請(qǐng)求處理器關(guān)聯(lián)起來(lái)，當(dāng)客戶端向服務(wù)器發(fā)送命令請(qǐng)求時(shí)，套接字就會(huì)產(chǎn)生AE_READABLE事件，引發(fā)命令請(qǐng)求處理器執(zhí)行，并執(zhí)行相應(yīng)的套接字讀入操作

• 命令回復(fù)處理器：當(dāng)服務(wù)器有命令回復(fù)需要傳遞給客戶端時(shí)，服務(wù)端會(huì)將客戶端套接字的AE_WRITABLE事件和命令回復(fù)處理器關(guān)聯(lián)起來(lái)，當(dāng)客戶端準(zhǔn)備好接收服務(wù)器傳回的命令回復(fù)時(shí)，就會(huì)產(chǎn)生AE_WRITABLE事件，引發(fā)命令回復(fù)處理器執(zhí)行，并執(zhí)行相應(yīng)的套接字寫(xiě)入操作

一次完整的客戶端與服務(wù)端連接事件

• 服務(wù)器監(jiān)聽(tīng)套件字的AE_READABLE事件，當(dāng)客戶端發(fā)送連接請(qǐng)求產(chǎn)生AE_READABLE事件，服務(wù)端會(huì)對(duì)客戶端的連接請(qǐng)求進(jìn)行應(yīng)答，將客戶端套接字的AE_READABLE事件與命令請(qǐng)求處理器關(guān)聯(lián)，客戶端可以向服務(wù)端發(fā)送命令請(qǐng)求了

• 客戶端向服務(wù)端發(fā)送一個(gè)命令請(qǐng)求，客戶端套接字將產(chǎn)生AE_READABLE事件，引發(fā)命令處理器去執(zhí)行，執(zhí)行命令將產(chǎn)生相應(yīng)的命令回復(fù)，服務(wù)端將客戶端套接字的AE_WRITABLE事件與命令回復(fù)處理器關(guān)聯(lián)

• 客戶端嘗試讀取命令回復(fù)時(shí)，客戶端套接字將產(chǎn)生AE_WRITABLE事件，觸發(fā)命令回復(fù)處理器執(zhí)行，當(dāng)命令回復(fù)處理器將命令回復(fù)全部寫(xiě)入套接字之后，服務(wù)器就會(huì)接觸客戶端套接字的AE_WRITABLE事件與命令回復(fù)處理器之間的關(guān)聯(lián)

時(shí)間事件

Redis的時(shí)間事件分為定時(shí)事件和周期性事件。一個(gè)時(shí)間事件由三個(gè)屬性組成：

id：服務(wù)器為時(shí)間時(shí)間創(chuàng)建的全局唯一IDwhen：記錄了時(shí)間時(shí)間的到達(dá)時(shí)間（毫秒精度的UNIX時(shí)間戳）timeProc：時(shí)間事件處理器

服務(wù)器所有的時(shí)間事件都放在一個(gè)無(wú)序鏈表中，每當(dāng)時(shí)間事件執(zhí)行器運(yùn)行時(shí)，它就遍歷整個(gè)鏈表，查找所有已到達(dá)的時(shí)間事件，并調(diào)用相應(yīng)的事件處理器。正常模式下的Redis服務(wù)器只使用serverCron一個(gè)時(shí)間事件，而在benchmark模式下，服務(wù)器也只使用兩個(gè)時(shí)間事件，所以不影響事件執(zhí)行的性能。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“redis事件處理流程的案例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!