高效能伺服器設計

先後檢視了haproxy

，l7sw

和lighttpd

的相關原始碼，無一例外，他們一致認為多路復用是效能最好的伺服器架構。事實也確實應該如此，程序的出現一方面就是為了儲存任務的執行上下文從而簡化應用程式設計，如果程式的邏輯結構不是很複雜，那麼用整個程序控制塊來儲存執行上下文未免有些大材小用，加上程序排程和其他的一些額外開銷，程式設計上的高效很可能會被執行時的低效所抵消。代價也是有的：程式設計工作將更加具有挑戰性。

體系結構選定之後，我們就要考慮更加細節的部分，比如說用什麼作業系統，用作業系統提供的那些api。在這方面，前輩們已經做過很多，我們只需要簡單的「拿來」即可，如果再去枉費唇舌，簡直就是浪費時間，圖財害命。high-performance server architecture

從根本上分析了導致伺服器低效的罪魁禍首：資料拷貝、（使用者和核心）上下文切換、記憶體申請（管理）和鎖競爭;the c10k problem

列舉並分析了unix、linux甚至是部分windows為提高伺服器效能而設計的一些系統呼叫介面，這篇文件的難能可貴之處還在於它一致保持更新;benchmarking bsd and linux

更是通過實測資料用圖表的形式把bsd和linux的相關系統呼叫的效能直觀地陳列在我們眼前，結果還是令人激動的：linux 2.6的相關系統呼叫的時間複雜度竟然是o(1)。

簡單的總結如下:

作業系統採用linux 2.6.x核心，不僅因為它的高效能，更因為它大開源（這並不是說其他的unix或者是bsd衍生物不開源）給程式設計帶來的便利，我們甚至可以把服務做到核心空間。

多路復用採用epoll的「電平觸發」(level triggered)模式，必要時可以採用「邊緣觸發」(edge triggered)，但要注意防止資料停滯。

為避免資料拷貝可以採用sendfile系統呼叫傳送小檔案，或者是檔案的小部分，注意避免sendfile因磁碟io而導致的阻塞。

如果服務操作設計大量磁碟io操作，應選用linux核心提供的非同步io機制

，其對應的使用者空間庫為libaio，注意：這裡提到非同步io庫並非目前glibc中附帶的非同步io實現。

如果同時有多個資料需要傳輸，採用writev/readv來減少系統呼叫所帶來的上下文切換開銷，如果資料要寫到網路套接字檔案描述符，這也能在一定程度上防止網路上出現比較小幀，為此，還可以有選擇地開啟tcp_cork選項。

實現自己的記憶體管理，比如說快取資料，復用常用資料結構等。

用多執行緒替代多程序，執行緒庫當然選擇nptl。

避免程序/執行緒間非必要的同步，保持互斥區的短小。

上面這些瑣碎的細節在esr看來可能都是過早優化，他可能又會建議我們等待硬體的公升級。哈哈，提醒還是不無道理的，演算法的設計部分，我們更要下大力氣，因地制宜地降低演算法的時間複雜度。為什麼不提空間複雜度呢？記憶體的**還是相對低廉吧，不過還是不要忘記現在的計算機瓶頸多在記憶體的訪問。

有一點需要提醒一下，目前**p系統和多核心cpu比較常見，如果還是僅採用單程序（執行緒）的多路復用模型，那麼同一時間將只有乙個cpu為這個程序（執行緒）服務，並不能充分發揮cpu的計算能力，所以需要至少cpu（cpu核心）數目個程序（執行緒）來分擔系統負擔。有乙個變通的解決方案：不用修改原始碼，在伺服器上執行兩個服務程式的例項，當然這個時候服務埠應該是不同的，然後在其前端放置負載均衡器將流量和連線平均分配到兩個服務埠，可以簡單的通過dnat來實現負載均衡。其實，這個時候我們已經把多cpu或者是多核系統看成了多個系統組成的集群。

為了提高伺服器的效能，單純的依靠提高單個伺服器的處理能力似乎不能奏效，況且配置越高的伺服器花銷也就越高，為此人們經常採用伺服器集群的方式，通過把計算盡可能地分配到相對比較廉價的機器上單獨完成，籍此來提公升伺服器的整體效能，事實證明，這種體系結構不僅是切實可行的，而且還能提高伺服器的可用性，容錯能力也較強。在網路伺服器方面，linux核心中的由國人

章文嵩先生設計的ip層負載均衡解決方案

lvs比較有名，還有就是工作於應用層的haproxy和剛剛起步的l7sw。

參考鏈結:

linux scalability effort homepage

高效能伺服器設計

高效能伺服器設計

高效能伺服器設計

高效能伺服器設計1

相關推薦