本篇文章為你解答以下問題:
- 0:redis單執行緒的實作流程是怎樣的?
- 1:redis哪些地方用到了多執行緒,哪些地方是單執行緒?
- 2:redis多執行緒是怎么實作的?
- 3:redis多執行緒是怎么做到無鎖的?
0:redis單執行緒的實作流程是怎樣的?
Redis一開始是單執行緒模型,在一個執行緒中要同時處理兩種事件:檔案事件和時間事件
檔案事件主要是網路I/O的讀寫,請求的接收和回復
時間事件就是單次/多次執行的定時器,如主從復制、定時洗掉過期資料、字典rehash等
redis所有核心功能都是跑在主執行緒中的,像aof檔案落盤操作是在子執行緒中執行的,那么在高并發情況下它是怎么做到高性能的呢?
由于這兩種事件在同一個執行緒中執行,就會出現互相影響的問題,如時間事件到了還在等待/執行檔案事件,或者檔案事件已經就緒卻在執行時間事件,這就是單執行緒的缺點,所以在實作上要將這些影響降到最低,那么redis是怎么實作的呢?
定時執行的時間事件保存在一個鏈表中,由于鏈表中任務沒有按照執行時間排序,所以每次需要掃描單鏈表,找到最近需要執行的任務,時間復雜度是O(N),redis敢這么實作就是因為這個鏈表很短,大部分定時任務都是在serverCron方法中被呼叫,從現在開始到最近需要執行的任務的開始時間,時長定位T,這段時間就是屬于檔案事件的處理時間,以epoll為例,執行epoll_wait最多等待的時長為T,如果有就緒任務epoll會回傳所有就緒的網路任務,存在一個陣列中,這時我們知道了所有就緒的socket和對應的事件(讀、寫、錯誤、掛斷),然后就可以接收資料,決議,執行對應的命令函式,
如果最近要執行的定時任務時間已經過了,那么epoll就不會阻塞,直接回傳已經就緒的網路事件,即不等待,
總之單執行緒,定時事件和網路事件還是會互相影響的,正在處理定時事件網路任務來了,正在處理網路事件定時任務的時間到了,所以redis必須保證每個任務的處理時間不能太長,
redis處理流程如下:
1:服務啟動,開始網路埠監聽,等待客戶端請求
2:客戶端想服務端發起連接請求,創建客戶端連接物件,完成連接
3:將socket資訊注冊到epoll,設定超時時間為時間事件的周期時長,等待客戶端發起請求
4:客戶端發起操作資料庫請求(如GET)
5:epoll收到客戶端的請求,可能多個,按照順序處理請求
6:接收請求引數,接收完成后決議請求協議,得到請求命令
7:執行請求命令,即操作redis資料庫
8:將結果回傳給客戶端
1:redis哪些地方用到了多執行緒,哪些地方是單執行緒?
Redis多執行緒和單執行緒模型對比如下圖:

從上圖中可以看出只有以下3個地方用的是多執行緒,其他地方都是單執行緒:
1:接收請求引數
2:決議請求引數
3:請求回應,即將結果回傳給client
很明顯以上3點各個請求都是互相獨立互不影響的,很適合用多執行緒,特別是請求體/回應體很大的時候,更能體現多執行緒的威力,而操作資料庫是請求之間共享的,如果使用多執行緒的話適合讀寫鎖,而操作資料庫本身是很快的(就是對map的增刪改查),單執行緒不一定就比多執行緒慢,當然也有可能是作者偷懶,懶得實作罷了,但這次的多執行緒模型還是值得我們學習一下的,
2:redis多執行緒是怎么實作的?
先大致說一下多執行緒的流程:
1:服務器啟動時啟動一定數量執行緒,服務啟動的時候可以指定執行緒數,每個執行緒對應一個佇列(list *io_threads_list[128]),最多128個執行緒,
2:服務器收到的每個請求都會放入全域讀佇列clients_pending_read,同時將佇列中的元素分發到每個執行緒對應的佇列io_threads_list中,這些作業都是在主執行緒中執行的,
3:每個執行緒(包括主執行緒和子執行緒)接收請求引數并做決議,完事后在client中設定一個標記CLIENT_PENDING_READ,標識引數決議完成,可以操作資料庫了,(主執行緒和子執行緒都會執行這個步驟)
4:主執行緒遍歷佇列clients_pending_read,發現設有CLIENT_PENDING_READ標記的,就操作資料庫
5:操作完資料庫就是回應client了,回應是一組函式addReplyXXX,在client中設定標記CLIENT_PENDING_WRITE,同時將client加入全域寫佇列clients_pending_write
6:主執行緒將全域佇列clients_pending_write以輪訓的方式將任務分發到每個執行緒對應的佇列io_threads_list
7:所有執行緒將遍歷自己的佇列io_threads_list,將結果發送給client
3:redis多執行緒是怎么做到無鎖的?
上面說了多執行緒的地方都是互相獨立互不影響的,但是每個執行緒的佇列就存在兩個兩個執行緒訪問的情況:主執行緒向佇列中寫資料,子執行緒消費,redis的實作有點反直覺,按正常思路來說,主執行緒在往佇列中寫資料的時候加鎖;子執行緒復制佇列&并將佇列清空,這個兩個動作是加鎖的,子執行緒消費復制后的佇列,這個程序是不需要加鎖的,按理來說主執行緒和子執行緒的加鎖動作都是非常快的,但是redis并沒有這么實作,那么他是怎么實作的呢?
redis多執行緒的模型是主執行緒負責搜集任務,放入全域讀佇列clients_pending_read和全域寫佇列clients_pending_write,主執行緒在將佇列中的任務以輪訓的方式分發到每個執行緒對應的佇列(list *io_threads_list[128])
1:一開始子執行緒的佇列都是空,主執行緒將全對佇列中的任務分發到每個執行緒的佇列,并設定一個佇列有資料的標記(_Atomic unsigned long io_threads_pending[128]),io_threads_pending[1]=5表示第一個執行緒的佇列中有5個元素
2:子執行緒死回圈輪訓檢查io_threads_pending[index] > 0,有資料就開始處理,處理完成之后將io_threads_pending[index] = 0,沒資料繼續檢查
3:主執行緒將任務分發到子執行緒的佇列中,自己處理自己佇列中的任務,處理完成后,等待所有子執行緒處理完所有任務,繼續收集任務到全域佇列,在將任務分發給子執行緒,這樣就避免了主執行緒和子執行緒同時訪問佇列的情況,就必須加鎖了,因為任務是平均分配到每個佇列的,所以每個佇列的處理時間是接近的,等待的時間會很短,
4:原始碼執行流程
為了方便你看原始碼,這里加上一些代碼的執行流程
啟動socket監聽,注冊連接處理函式,連接成功后創建連接物件connection,創建client物件,通過aeCreateFileEvent注冊client的讀事件
main -> initServer -> acceptTcpHandler -> anetTcpAccept -> anetGenericAccept -> accept(獲取到socket連接句柄)
connCreateAcceptedSocket -> connCreateSocket -> 創建一個connection物件
acceptCommonHandler -> createClient創建client連接物件 -> connSetReadHandler -> aeCreateFileEvent -> readQueryFromClient
main -> aeMain -> aeProcessEvents -> aeApiPoll(獲取可讀寫的socket) -> readQueryFromClient(如果可讀) -> processInputBuffer -> processCommandAndResetClient(多執行緒下這個方法在當前流程下不會執行,而由主執行緒執行)
在多執行緒模式下,readQueryFromClient會將client資訊加入server.clients_pending_read佇列,listAddNodeHead(server.clients_pending_read,c);
主執行緒會將server.clients_pending_read中的資料分發到子執行緒的佇列(io_threads_list)中,子執行緒會呼叫readQueryFromClient就行引數決議,主執行緒分發完任務后,會執行具體的操作資料庫的命令,這塊是單執行緒
如果引數決議完成會在client->flags中加一個標記CLIENT_PENDING_COMMAND,在主執行緒中先判斷client->flags & CLIENT_PENDING_COMMAND > 0,說明引數決議完成,才會呼叫processCommandAndResetClient,之前還擔心如果子執行緒還在做引數決議,主執行緒就開始執行命令難道不會有問題嗎?現在一切都清楚了
main -> aeMain -> aeProcessEvents -> beforeSleep -> handleClientsWithPendingReadsUsingThreads -> processCommandAndResetClient -> processCommand -> call
讀是多次讀:socket讀緩沖區有資料,epoll就會一直觸發讀事件,所以讀可能是多次的
寫是一次寫:往socket寫資料是在子執行緒中執行的,直接回圈直到資料寫完位置,就算某個執行緒阻塞了,也不會像單執行緒那樣導致所有任務都阻塞
執行完相關命令后,就是將結果回傳給client,回復client是一組函式,我們以addReply為例,說一下執行流程,執行addReply還是單執行緒的,將client資訊插入全域佇列server.clients_pending_write,
addReply -> prepareClientToWrite -> clientInstallWriteHandler -> listAddNodeHead(server.clients_pending_write,c)
在主執行緒中將server.clients_pending_write中的資料以輪訓的方式分發到多個子執行緒中
beforeSleep -> handleClientsWithPendingWritesUsingThreads -> 將server.clients_pending_write中的資料以輪訓的方式分發到多個執行緒的佇列中io_threads_list
list *io_threads_list[IO_THREADS_MAX_NUM];是陣列雙向鏈表,一個執行緒對應其中一個佇列
子執行緒將client中的資料發給客戶端,所以是多執行緒
server.c -> main -> initThreadedIO(啟動一定數量的執行緒) -> IOThreadMain(執行緒執行的方法) -> writeToClient -> connWrite -> connSocketWrite
網路操作對應的一些方法,所有connection物件的type欄位都是指向CT_Socket
ConnectionType CT_Socket = {
.ae_handler = connSocketEventHandler,
.close = connSocketClose,
.write = connSocketWrite,
.read = connSocketRead,
.accept = connSocketAccept,
.connect = connSocketConnect,
.set_write_handler = connSocketSetWriteHandler,
.set_read_handler = connSocketSetReadHandler,
.get_last_error = connSocketGetLastError,
.blocking_connect = connSocketBlockingConnect,
.sync_write = connSocketSyncWrite,
.sync_read = connSocketSyncRead,
.sync_readline = connSocketSyncReadLine
};
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/227699.html
標籤:其他
上一篇:太贊了!首發獨家Java飛滴專案實戰視頻教程!可以讓你寫到簡歷上的專案, 限時分享!
下一篇:Elasticsearch搜索資料匯總