Redis 單機處理邏輯。

面對高吞吐量的訪問需求，同乙個db這個key-value的hashtable面臨著來自客戶端的併發訪問。這個過程中hashtable可能會訪問相同桶、rehase，如何保證客戶端併發訪問時hashtable的執行緒安全？redis的做法很直接：單執行緒的處理來自所有客戶端的併發請求。

redis伺服器端對於命令的處理是單執行緒的，但是i/o層面卻同時面向多個客戶端併發的提供服務，併發到內部單執行緒的轉化通過多路復用框架實現，如下圖所示。

上圖中粗線描述的就是這個單執行緒主迴圈的主要邏輯：

readqueryfromclient處理來自客戶端的資料，他會讀取每乙個完整的命令並執行，再將執行結果暫存，待客戶端對應fd準備好寫時向客戶端寫入。所以該方法需要為fd註冊ae_writable事件並以sendreplytoclient作為處理器。所以該方法需要為fd註冊ae_writable事件並以sendreplytoclient作為處理器。對於multi（批處理的事務），需等到multi包含乙個全部的命令時才進行執行；

sendreplytoclient將暫存的執行結果寫回客戶端。

在主線程的主迴圈執行過程中，有乙個物件持續的流轉並記錄著redis的事件狀態，redis就是由這些事件驅動運轉的：

typedef struct aeeventloop  aeeventloop;

其中events和fired共同維護著和多路復用框架互動的各個事件，而aetimeevent*以鍊錶的形式維護著待處理的定時任務（aetimeevent）：

typedef strut aetimeevent aetimeevent;

其中兩個when_表示這個任務下一次執行時間，timeproc表示定時任務的執行邏輯。timeproc函式的返回值為這個任務執行完了以後下次再執行的時間間隔，對於週期性的定時任務，timeproc每次總是返回乙個正數（執行間隔），而對於一次性的任務timeproc則返回ae_nomore表示「不存在下次執行」。

上節提到「aeapipoll的等待超時時間取決於定時任務」，redis只有乙個執行緒，迴圈的處理來自客戶端的請求和定時任務，如何保證每個定時任務按時執行呢？下圖展示了定時任務的執行過程。

如上圖所示，aeapipoll方法最多等到待處理定時任務中最近的乙個的執行時刻，如果多路復用框架未返回已ready的事件，則redis直接執行定時任務。

每次乙個aetimeevent執行結束後，都會根據其timeproc方法的返回值更改其下次執行的時間（when_sec/when_ms），如果timeproc返回ae_nomore，則將aetimeevent刪除之。

預設情況下，redis指揮有乙個週期性定時任務servercron存在，他負責：

servercron通過redisserver類的hz屬性進行控制。

Redis 單機處理邏輯。

redis單機安裝

Redis 搭建（單機）

redis單機安裝

Redis 單機處理邏輯。

redis單機安裝

Redis 搭建（單機）

redis單機安裝

相關推薦