首頁 >資料庫 >Redis >一文帶你快速了解Redis中的線程IO模型

一文帶你快速了解Redis中的線程IO模型

青灯夜游
青灯夜游轉載
2021-12-21 10:19:322504瀏覽

Redis是單線程的,但為什麼那麼快尼?原因之一就是redis使用非阻塞IO與多路復用處理大量的客戶端連線。以下這篇文章就來帶大家了解一下Redis中的線程IO模型,希望對大家有幫助!

一文帶你快速了解Redis中的線程IO模型

Redis是一個單線程的應用程序,NodeJs、Nginx都是單線程,它們都屬於伺服器高效能的典範。 【相關推薦:Redis影片教學

Redis之所以是單執行緒還能這麼快的原因:

其一是因為它所有的資料都在內存當中,所有的運算都是記憶體層級的運算,所以使用redis時,要注意時間複雜度為O(n)的指令,因為是單線程的,如果資料量太大,會讓其他指令被阻塞等待;

其二是因為redis使用非阻塞IO與多路復用處理大量的客戶端連線。

非阻塞IO

當我們使用套接字的讀寫方法時,預設是阻塞的,

即呼叫read方法傳遞一個參數n,表示最多讀取n個位元組後返回,如果一個位元組都沒有,線程就會在read方法這裡持續等待,直到有資料過來或連接被關閉,read方法此時返回,線程才能執行下面的邏輯,

write方法通常不會阻塞,除非核心為套接字分配的寫緩衝區滿了,write方法才會阻塞,一直到快取區中有空間閒出來。

下圖是套接字讀寫的細節流程。

一文帶你快速了解Redis中的線程IO模型

非阻塞IO在使用套接字時提供了一個選項Non_Blocking,當這個選項開啟時,讀寫方法不會阻塞,而是能讀多少讀多少,能寫多少寫多少,

能讀多少取決與內核為套接字分配的讀取緩衝區的數據字節數,能寫多少取決於內核為套接字寫緩衝區分配的數據位元組數,

讀寫方法都會透過傳回值告訴程式讀寫了多少位元組數。

非阻塞IO意味著讀寫時,執行緒不必再被阻塞著,讀寫可以瞬間完成,執行緒可以繼續往下做別的事情。

多路復用(事件輪詢)

非阻塞IO雖然很快,但是也帶來一個問題,線程讀數據,讀了一部分就返回了,沒有讀完,剩下的數據何時繼續讀取? ,寫數據,緩衝區滿了,沒有寫完,剩下的數據何時繼續寫?

當可以繼續讀取或可以繼續寫時,應該給應用程式一個通知,告訴應用程式可以繼續讀取或繼續寫,事件輪詢API就是用來處理這個問題的。

select

作業系統提供了一個select函數給使用者程序,輸入是讀寫描述符列表read_fds & write_fds,輸出是與之對應的可讀可寫事件,

同時也提供了timeout參數,線程最多等待timeout的時間,在這段期間有事件過來,方法立刻返回,線程往下處理,如果超過timeout時間,方法也會返回,

如果拿到事件了,線程即可挨個處理相應的事件,處理完了以後繼續調用select api 輪詢,所以該線程其實是一個死循環,不停的select,不停的處理,來回這樣,這個死循環稱為事件循環,一個循環即一個週期。

一文帶你快速了解Redis中的線程IO模型

事件循環偽代碼:

while True
    read_events, write_events = select(read_fds, write_fds, timeout)
    for event in read_events:
        handle_read(event.fd)
    for event in write_events:
        handle_write(event.fd)
    handle_others() # 做其他的逻辑处理,处理定时任务等等

透過select函數我們可以處理多個通道描述子的讀寫事件,所以將select這類的系統函數呼叫稱為多路復用API,

現代作業系統的多路復用API已經不使用select系統調用,改用epoll(linux)和kqueue(FreeBSD、macosx),

select的效能在描述符變多時會變得很差,epoll與select使用起來略有差異,不過都可以用上面的偽代碼理解,都是當描述符發生事件時,循環對描述符的事件做出處理,

serversocket物件的讀取操作是指呼叫accept接受客戶端新連接,何時有連接來臨,也是透過select呼叫的讀取事件通知的。

Java中的NIO技術就是事件輪詢,其他語言也有這個技術。

指令佇列

Redis為每個客戶端套接字關聯一個指令佇列,客戶端發出的指令透過佇列進行先進先出的順序處理。

回應佇列

同樣Redis傳回的結果也透過為每個客戶端關聯的一個佇列傳回,如果佇列為空,則暫時不需要去取得寫事件,

此時會將該客戶端描述符從write_fds裡移除,等隊列有資料的時候,再將描述符放進去,這樣可以避免select系統呼叫回傳寫事件時,發現沒資料可寫,造成空輪詢、無用輪詢,對機器CPU的消耗。

定時任務

伺服器不單要回應IO事件,有些其他的事情也需要處理,例如應用程式本身的定時任務,如果執行緒阻塞在select呼叫上,等待select的返回,這會造成有些定時任務到期了,卻沒有執行,

Redis的定時任務記錄在一個稱為最小堆的資料結構中,這個堆中,最快要執行的任務排在最上方,每個循環週期裡,redis會對堆中已經到時間點的任務進行處理,

處理完畢後,將堆中即將要執行的任務還需要的時間記錄下來,再次調用select時,這個時間就是timeout的值,在這段期間內不會有其他任務需要執行了,redis可以放心的最多阻塞這麼久,然後到時間後進行相應的處理。

NodeJs和Nginx的事件處理原理和Redis也是類似的形式。

更多程式相關知識,請造訪:程式設計影片! !

以上是一文帶你快速了解Redis中的線程IO模型的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文轉載於:juejin.cn。如有侵權,請聯絡admin@php.cn刪除