Linux 高效能伺服器程式框架

2021-10-08 05:23:48 字數 1688 閱讀 9836

伺服器解構主要分為如下三個主要模組:

1、i/o處理單元。接收客戶端傳送的資料都屬於i/o處理單元。

2、邏輯單元。接收到資料之後進行的一些處理都屬於邏輯單元。

3、儲存單元。

如下圖所示(伺服器程式設計框架):

1、c/s模型

c就是客戶端,s就是伺服器。所以這個模型也稱客戶端/伺服器模型。

c/s模型如下圖所示:

現在大多數的公司用的都是c/s模型。也就是一組伺服器,所有的客戶端要上網的時候都要訪問這個伺服器。

c/s模型的邏輯

c/s模型的邏輯很簡單,伺服器啟動後,首先建立乙個(或多個)監聽socket,並呼叫bind函式將其繫結到伺服器感興趣的埠上,然後呼叫listen函式等待客戶連線。伺服器穩定執行之後,客戶端就可以呼叫connect函式向伺服器發起連線了。由於客戶連線請求是隨機到達的非同步事件,伺服器需要使用某種i/o模型來監聽這一事件。

c/s模型的缺點

c/s模型非常適合資源相對集中的場合,並且它的實現也很簡單,但其缺點也很明顯:伺服器是通訊的中心,當訪問量過大時,可能所有客戶都將得到很慢的響應。下面討論的p2p模型解決了這個問題。

2、p2p模型

p2p模型也就是點對點模型。

以下是兩種p2p模型。

p2p 模型比c/s模型更符合網路通訊的實際情況。它摒棄了以伺服器為中心的格局,讓網路上所有主機重新回歸對等的地位。p2p模型使得每台機器在消耗服務的同時也給別人提供服務,這樣資源能夠充分、自由地共享。雲計算機群可以看作p2p模型的乙個典範。但p2p模型的缺點也很明顯:當使用者之間傳輸的請求過多時,網路的負載將加重。

1、同步i/o和非同步i/o模型的區別

2、幾種i/o模型的對比

i/o模型

讀寫操作和阻塞階段

阻塞i/o

程式阻塞於讀寫函式

i/o復用

程式阻寓於i/o復用系統呼叫,但可同時監聽多個10事件。對i/o本身的讀寫操作是非阻塞的。

sigio訊號

訊號觸發讀寫就緒事件,使用者程式執行讀寫操作。程式沒有阻塞階段

非同步i/o

核心執行讀寫操作並觸發讀寫完成事件。程式沒有限塞階段

伺服器程式通常需要處理三類事件:i/o事件、訊號及定時事件。這兩種高效的事件處理模式是:reactor模式和proactor模式

1、reactor模式

1.1.1 reactor模式要求主線程只負責監聽檔案描述符上是否有事件發生,有的話立即將該事件通知工作執行緒。除此之外,主線程不做任何其他實質性的工作,讀寫資料,接收新的連線以及處理客戶請求均在工作執行緒中完成。

1.1.2 工作流程

2、proactor模式

與reactor完全不同。proactor模式將所有i/o操作都交給主線程和核心來處理,工作執行緒僅僅負責業務邏輯。所以proactor更符合伺服器程式設計框架。

2.1 工作流程

高效能的伺服器處理框架

終於開始學習epoll了,雖然不明白的地方還是很多,但從理論到實踐,相信自己動手去寫乙個具體的框架後,一切會清晰很多。1 首先需要乙個記憶體池,目的在於 減少頻繁的分配和釋放,提高效能的同時,還能避免記憶體碎片的問題 能夠儲存變長的資料,不要很傻瓜地只能預分配乙個最大長度 基於slab演算法實現記憶...

linux高效能伺服器程式設計

linux高效能伺服器程式設計 當當網 亞馬遜 目錄 第一章 tcp ip協議族 第二章 ip協議族 第三章 tcp協議詳解 第四章 tcp ip通訊案例 訪問internet 第五章 linux網路程式設計基礎api 第六章 高階io函式 第七章 linux伺服器程式規範 第八章 高效能伺服器框架...

linux 高效能伺服器程式設計

1.高效能定時器 時間輪,時間堆 處理超時時間,如nginx使用紅黑樹,找出最可能超時的事件 2.高效能伺服器程式框架 nginx 使用的是基於事件模型,epoll,不阻塞,非同步處理 兩種高效的事件處理模式 reactor模式 proactor模式 兩種高效的併發模式 半同步 半非同步模式 領導者...