Redis為什么這么快？

| 作者 吳顯堅，騰訊云資料庫高級工程師，參與過360開源專案Pika的研發作業，現從事redis資料庫研發作業，

Redis服務器是一個事件驅動程式, 事件是Redis服務器的核心, 它處理兩項重要的任務, 一個是IO事件(檔案事件), 另外一個是時間事件. Redis服務器通過套接字與客戶端進行連接, 而檔案事件可以理解為服務器對套接字操作的抽象. 服務器與客戶端的通信會產生相應的檔案事件, 而服務器則通過監聽并處理這些事件來完成一系列網路通信操作. 另外Redis內部有一些操作(從Redis4.0的代碼分析目前時間事件只有serverCron)需要在給定的時間點執行, 而時間事件就是Redis服務器對這類定時操作的抽象，

一、aeEventLoop

在分析具體代碼之前, 我們先了解一下在事件處理中處于核心部分的aeEventLoop到底是什么:

/* State of an event based program */

創建aeEventLoop只需要一個setsize引數, 它標識了當前aeEventLoop最大可以監聽的檔案描述符數(通常redis傳入server.maxclients+CONFIG_FDSET_INCR,也就是在用戶指定的最大客戶端連接數的基礎上再額外增加128, 這128可以用于Redis內部打開AOF,RDB檔案以及主從, 集群互相通信所對應的檔案句柄), 創建aeEventLoop時, aeFileEvent和aeFiredEvent陣列的大小就由setsize確定，

1. aeFileEvent

內部以掩碼的形式存盤了當前套接字關心的事件(可讀/可寫事件), 內部還有兩個函式指標指向可讀/可寫事件發生時應該呼叫的函式, 另外還有一個無型別的指標指向相關聯的資料, 這里需要注意的是, events是一個陣列, 而套接字就是作為下標來進行索引對應aeFileEvent, 例如我當前關心的套接字是9, 那么events[9]就是它對應的檔案事件資料結構(csapp中提到過, 當我們呼叫系統函式回傳描述符數字時, 回傳的描述符總是在行程中當前沒有打開的最小描述符, 所以我們無需擔心檔案描述符被反復的創建銷毀, 而越來越大的問題)，

2. aeFiredEvent

內部以掩碼的形式存盤了當前已經觸發的事件和對應的套接字, 實際上fired陣列只有在呼叫aeApiPoll的時候才會被賦值, 例如當前發現有套接字6, 8有可讀事件, 而套接字10有可寫事件, 那么fired陣列的前三個元素會被賦值{fd = 6, mask =AE_READABLE}, {fd = 8, mask = AE_READABLE}, {fd = 10, mask = AE_WRITABLE}, 緊接著我們以6為索引, 找到檔案事件資料結構events[6],然后發現觸發的是可讀事件, 我們再呼叫events[6]中rfileProc來處理可讀事件，

aeEventLoop *aeCreateEventLoop(int setsize){

對于時間事件, aeEventLoop中有一個timeEventHead指標指向第一個時間事件, 由于aeEventLoop創建之初, 內部沒有任何時間事件, 所以初始化時timeEventHead指向NULL, 每當有新的時間事件時, 總會被添加到timeEventHead頭部, 由于aeTimeEvent結構體中有next指標可以指向下一個aeTimeEvent結構體, 所以只要我們獲取timeEventHead就能遍歷當前所有的時間事件了, 另外有一個細節需要注意, 最后一個aeTimeEvent結構體中的next指標指向的是timeEventHead, 所以所有時間事件實際上就是由一個環形鏈表串連起來的，

二、檔案事件

在介紹中有提到過檔案事件實際上就是服務器對套接字操作的抽象, 當套接字有可讀\寫事件觸發的時候, 我們需要呼叫相應的處理函式, 下面先看一下跟檔案事件相關的結構體:

/* File event structure */

在aeEventLoop初始化的時候會為aeFileEvent陣列(events)分配空間, 陣列的大小由引數setsize指定,表明了當前Redis最大打開的套接字的大小, 套接字與aeFileEvent一一對應, 也就是說我們可以通過套接字數值作為索引到events陣列中找到他對應的aeFileEvent物件，

當我們在aeEventLoop中注冊一個檔案事件時, 首先我們判斷傳入的套接字對events陣列是否有越界行為, 若沒有越界行為, 我們便可以獲取與當前套接字對應的aeFileEvent物件, 然后呼叫aeApiAddEvent將當前的檔案描述符以及監聽的事件注冊到底層IO多路復用機制(epoll, select, evport, kqueue其中之一)中, 另外我們還需要指定當可讀/可寫事件發生時需要呼叫的函式,另外當前檔案事件的一些私有資料被存放在clientData指向的物件當中，

int aeCreateFileEvent(aeEventLoop *eventLoop,int fd, int mask,

三、時間事件

Redis內部的時間事件實際可以分為兩類, 一類是定時事件, 也就是需要在未來某一個時間點觸發的事件(只觸發一次), 另外一類是周期性事件,和前面的定時事件只觸發一次不同, 周期性事件是每隔一段時間又會重新觸發一次，

Redis使用了timeProc指向函式的回傳值來判斷當前屬于哪類事件, 若函式回傳AE_NOMORE(也就是-1),說明當前事件無需再次觸發(將id置洗掉標記AE_DELETED_EVENT_ID), 若函式回傳一個大于等于0的值n, 說明再等待n秒, 該事件需要再重新被觸發(根據回傳值更新when_sec和when_ms),在博客開頭提到的serverCron時間事件實際上就是一個周期性事件, 函式末尾會回傳1000/server.hz, server.hz默認被設定為10, 也就是說serverCron平均每間隔100ms會被呼叫一次，

/* Time event structure */

Redis呼叫aeCreateTimeEvent來創建一個時間任務, 實作非常簡單, 傳參我們關注一下milliseconds和proc即可, 前者指定了時間事件距離當前的觸發時間, 后者指定了時間事件觸發時應呼叫的函式, 內部通過aeAddMillisecondsToNow將當前定時任務觸發的時間戳計算出來賦值給when_sec和when_ms, 然后再將timeProc指向時間事件到達時應該呼叫的函式，

在完成了aeTimeEvent結構體內部變數賦值之后, 最后將其添加到aeEventLoop內部的存盤定時間事件的環形鏈表的頭部中(這里需要注意的是, 由于我們總是將新的時間事件加入環形鏈表的頭部, 所以時間事件觸發的時間先后并不是在環形鏈表中有序的, 我們需要將環形鏈表遍歷完畢才能保證當前已經到達的時間事件都已經被處理完畢, 不過由于在開頭提到過, 目前Redis只存在serverCron一個時間事件, 所以我們無需擔心遍歷環形鏈表影響服務性能), 此時一個時間事件就算創建完成了，

static void aeAddMillisecondsToNow(long longmilliseconds, long *sec, long *ms) {

Redis通過aeDeleteTimeEvent函式來洗掉一個時間任務, 傳參只有一個待洗掉時間事件的id, 我們發現這里的洗掉實際上是一種惰性洗掉, 將aeTimeEvent中的id標記為AE_DELETED_EVENT_ID, 而不是直接將aeTimeEvent物件從鏈表中洗掉并且釋放, 個人認為這么實作的原因更多是為了安全考慮以及代碼的簡潔性, 考慮在一個時間事件中本來想洗掉另外一個時間事件, 但是由于id填錯, 誤刪成自己了, 此時如果釋放自身aeTimeEvent物件, 這是十分危險的，

int aeDeleteTimeEvent(aeEventLoop *eventLoop,long long id)

四、事件的調度與執行

Redis是單執行緒的, 內部是一直處于aeMain中的while回圈中, 而回圈內部不斷呼叫aeProcessEvents函式, 該函式會對上面提到的檔案事件和時間事件進行調度, 決定何時處理檔案事件以及時間事件，

void aeMain(aeEventLoop *eventLoop) {

實際上aeProcessEvents函式內部做的事情也非常簡單, 下面進行了梳理:

1. 首先呼叫aeSearchNearestTimer獲取到達時間距離當前最近的時間事件；

2. 計算上一步獲取到的時間事件還有多久才可以觸發, 并且將結果記錄到一個struct timeval*指標指向的結構體中(若在步驟一中沒有獲取到時間事件物件, 那么指標為NULL)；

3. 阻塞并等待檔案事件的產生, 最大的阻塞時間由步驟二決定(步驟二指標為NULL的場景表示當前沒有時間事件, 我們可以永遠阻塞, 直到有檔案事件到達)；

4. 如果在最大阻塞時間內獲取到了檔案事件, 則根據檔案事件的型別呼叫對應的讀事件處理函式或者寫事件處理函式；

5. 遍歷時間事件鏈表, 在這個程序中可能會遇到id為AE_DELETED_EVENT_ID的代表已經做了洗掉標記的時間事件, 需要將該時間事件從鏈表中移除, 并且進行釋放, 如遇到已經達到的時間事件, 則呼叫其系結的處理函式, 并且根據回傳值來判斷該事件時間是否需要在給定的時間內再重新觸發，

五、問題

Q1: 時間事件觸發的時間一定精準么?

A1: 時間事件的觸發并不能在指定的時間精準觸發, 一般都要比指定的時間稍晚一點, 此外在Redis單執行緒模型下, 時間事件都是串行執行的, 中間如果某個時間事件處理時間長, 更加影響了后面時間事件執行時間的精準性. 而且時間事件鏈表是無序的, 所以在極端場景下, 存在優先級低的時間事件比優先級高的事件先觸發的可能性, 不過好在目前Redis內部只有一個時間事件, 所以影響不會太大.

Q2: aeEventLoop在創建之初就指定了可監聽檔案描述符的數量, 之后又通過config set maxclients命令動態調整客戶端最大連接數是怎么實作的?

A2: 通過翻看原始碼了解到, aeEventLoop提供了aeResizeSetSize函式, 用戶重新分配events和fired陣列的大小, 使aeEventLoop可監聽的套接字數量得以調整, 當新的maxclients比原先要大的時候, 會呼叫該函式, 擴大aeEventLoop可監聽檔案描述符的數量, 以支持更多的客戶端連接.

int aeResizeSetSize(aeEventLoop *eventLoop,int setsize) {

六、總結

Redis對事件的處理方式十分巧妙, 檔案事件和時間事件之間相互配合, 充分的利用時間事件達到之前的這段時間等待和處理檔案事件, 這樣既避免了CPU的空轉檢查, 也能及時的處理檔案事件. 此外通過時間事件中timeProc函式的回傳值, 將時間事件的移除和再次觸發權完全交給了用戶, 使用起來更加靈活.

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其它

上一篇：只需三步！慢日志去無蹤

下一篇：IO問題成頑疾，鵝廠專家來教你