當前位置:旅游攻略大全網 - 酒店加盟 - Redis IO模型

Redis IO模型

我們的應用都部署在linux系統中,linux系統也是應用,是基於計算機硬件的操作系統軟件。當我們接收到壹個網絡傳輸時,計算機硬件的網卡會把從網絡上讀入linux的緩沖存儲器中的字節流寫入,然後用戶空間會調用linux的暴露接口,把linux的緩沖存儲器中的數據讀入用戶空間。這個讀操作是壹個IO。寫作也是如此。

不同的操作系統有不同的IO模型。下面是壹些Linux系統的IO模型。

這樣做是為了保護Linux操作系統,避免外部應用程序或人工直接操作內核系統。

線程在用戶空間運行時的狀態稱為用戶狀態。

線程在內核空間運行時的狀態稱為內核狀態。

IO的性能瓶頸:

A.在用戶模式和內核模式之間切換(數據復制)

B.讀寫線程的阻塞等待

linux的IO模型針對這兩點進行了優化。

當用戶應用線程調用linux操作系統的recvfrom函數讀取數據時,如果內核的緩沖內存中沒有數據,用戶線程會阻塞等待,直到內核的緩沖內存中有數據,然後將內核的緩沖內存中的數據復制到用戶應用內存中。

類似於排隊買包子,這個時候沒有包子,但是妳不知道有沒有包子。如果沒有饅頭,就只能在那裏等著,什麽都不做。等包子烤好了,再去拿,放進口袋裏。

問題:

當壹個線程被阻塞時,會導致後續所有線程被阻塞,即使後面的讀寫數據準備好了,也無法讀寫。

當用戶應用線程調用linux操作系統的recvfrom函數讀取數據時,如果內核的緩沖內存中沒有數據,那麽用戶線程會直接得到結果(沒有數據)而不需要等待,於是會發起另壹次recvfrom函數調用,直到內核的緩沖內存中有數據,然後將內核的緩沖內存中的數據復制到用戶應用內存中。

類似於妳排隊買包子,老板直接告訴妳沒有包子。妳已經知道結果了。妳壹遍又壹遍的問老板有沒有饅頭。在老板沒有告訴妳之前,妳不能把饅頭拿到口袋裏。

問題:

如果壹直沒有數據,線程會無限循環調用recvfrom函數,頻繁使用CPU資源,造成CPU資源的浪費。

內核)使用文件描述符來訪問文件。文件描述符是壹個非負整數。當打開壹個現有文件或創建壹個新文件時,內核將返回壹個文件描述符。讀寫文件還需要使用文件描述符來指定要讀寫的文件。文件包括音頻文件、常規文件、硬件設備等。,還包括網絡套接字。

IO復用就是用單線程監聽更多的文件描述符FD,當壹個文件描述符FD可讀可寫時接收壹個通知,避免無效等待,充分利用CPU資源。

用戶應用程序線程調用select函數來監聽多個FD文件描述符。如果沒有數據,還是要等。如果有就緒文件FD,說明有數據,那麽讀取對應的FD就緒文件數據。這時候內核會把文件FD集復制到用戶的內存中,然後遍歷FD集找到可以讀取的數據的FD,然後讀取。讀取後,它會將FD集復制到內核內存中。

類似於在餐廳排隊點餐。這時候有壹個服務員通過壹個平板監控廚房。妳只需要問服務員有沒有吃的。如果沒有,妳還是需要等,但是如果他有,服務員會通過監控知道有吃的,會讓妳點。

事實上,輪詢模式的原理與選擇模式的原理相似。不同的是在輪詢模式的底部增加了壹個event事件,分為read事件、write事件、exception事件等等。

流程:

A.首先添加要監控的事件,是讀事件還是寫事件,可以是多個事件。

b .將監控到的事件FD轉換成鏈表並存儲在內核緩沖區中。

c、內核緩沖區將事件FD鏈表復制到用戶緩沖區,返回就緒FD數量。

d .判斷用戶緩存中就緒FD的個數,如果大於0,則啟動便利事件FD鏈表。

輪詢模式的問題:

A.妳需要把整個FD鏈表從用戶空間復制到內核空間,輪詢後再復制到用戶空間。

B.poll無法知道具體是哪個ready FD事件,需要促成整個FD事件(鏈表)。

對比度選擇模式

因為使用鏈表,理論上事件的數量可以是無數的,但是隨著事件數量的增加,鏈表的遍歷性能會下降,當沒有準備好的事件時,仍然需要等待。

Epoll模式是在poll模式的基礎上改進的。首先將存儲事件的FD鏈表改為紅黑樹(理論上沒有上限),紅黑樹遍歷性能穩定。其次,將具體的就緒事件單獨復制,然後復制到用戶緩沖區,用戶緩沖區獲取就緒事件,不需要再次提高遍歷性能。

流程:

a .首先,註冊監控事件

B.將所有FD安裝在紅黑樹上。

c .當FD準備好時,調用回調函數將對應的FD復制到鏈表中。

d .將鏈表從內核緩沖區復制到用戶緩沖區,並返回鏈表大小n

E.用戶線程直接判斷n的大小,當n不為0時,可以直接讀取鏈表的數據(all ready FD)。

當用戶應用線程調用linux操作系統的sigaction函數時,直接返回,然後線程去做其他的事情。當數據到來時,內核空間會向用戶空間發送信號。此時用戶空間會調用recvfrom函數,將數據從內核空間緩沖區復制到用戶空間緩沖區,並對數據進行處理。

就類似於妳點完菜,服務員會給妳壹個號碼,然後妳的飯好了,服務員會叫妳的號碼,然後妳來取飯。

問題:

當調用過多線程時,對應的信號量會增加,SIGIO函數得不到及時處理,導致存儲信號的隊列溢出;而且內核空間和用戶空間頻繁與信號量交互,性能較差。

性能方面,也不錯,就是在實際開發中,需要控制它的線程並發,所以實現起來會很麻煩,所以很少用。

在三種IO復用方式中,epoll的效果最好。解決了選擇和輪詢模式中存在的問題。

Redis是epoll模式的IO模型。