高性能服務器本質論

一 服務器分類
從軟件性能角度，高性能服務器分：cpu密集型服務器/IO密集型服務器
(1)CPU密集型：該類服務器沒有對io的訪問/沒有同步點，性能瓶頸在於對cpu的充分利用。
典型的如轉發服務器/代理服務器/協議轉換類服務器/分佈式總線服務器等。
(2)IO密集型：該類服務器存在對cache/db/硬盤等的同步訪問，或者對fcgi/其餘服務器等的同步訪問。
簡單說有同步訪問點的均歸屬此類服務器。當前硬件基礎下，有同步操做的服務器，性能瓶頸均在同步點的返回快慢上，而非cpu。
二 網絡層機制
對上述兩類服務器，均須要一樣高效的網絡層機制。當前高效的網絡層也就是你們熟知的iocp/epoll/kqueue/port/dev.poll等，在各個os下使用宿主os推薦的高效網絡層機制，任何經過其餘機制繞過這些機制的作法都不可能達到最好性能。這裏推薦下boost.asio，文檔齊全，示例豐富，學習曲線平緩。
三 CPU密集型服務器設計
（1）單進程單線程是改類服務器的本質特徵。
整個進程只存在一個線程，全部代碼均運行在同一個線程中，均順序執行，任何地方不須要加鎖。因爲網絡線程的存在，實際上該類程序的惟一線程就是網絡線程，以linux爲例，就是epoll線程。
在多核狀況下，fork和cpu個數相同的進程數而且若是可能使用sched_setaffinity類函數將進程和cpu綁定。以充分利用多核性能。
該類服務器的表明：tuxedo/nginx.
（2）單進程多線程，但多線程均完成一樣的功能，彼此之間互不依賴/互不影響 ，這是該類服務器的變體。
單進程單線程無疑是該類服務器最理想最完美的實現。但有時候爲了簡化部署，簡化業務上報，業務自檢，統一日誌,尤爲是統計類日誌/配置動態生效等附加功能考慮，不得已犧牲少量性能而將上述「單進程單線程，fork多個充分利用多核」方案改造爲「獨立多線程充分利用多核」方案。
該方案中，多線程中的各個線程仍然是順序執行，任何地方不須要加鎖，均爲獨立的網絡線程。
相對方案(1)， 該方案編程更復雜，而linux下線程調度又不如進程高效，總體看爲方便性犧牲了少量性能。
該類服務器的表明：咱們的協議轉換網關/分佈式總線服務器等。
（3）高效算法
優化耗時較多算法/挑選合適容器，完成固定任務，儘可能減小cpu的運算量。
（4）錯誤設計：區分網絡線程/業務線程，將業務線程根據業務特色劃分各個線程階段。
對cpu密集型的服務器來講，關鍵在於充分利用cpu，儘可能減小無用代碼的執行。引如中間處理線程，意味着引入鎖切換/內存複製/更多無效代碼，不能否認，在已有協議棧狀況下，根據業務特色化分線程能夠簡化編程。單純的單一線程意味着更復雜的編碼，尤爲是涉及到更多中間狀態時。
在該場景下，有位牛人，對線程的點評：「線程是給那些不能將程序執行序轉換成狀態機的笨人用的」 這句話真是再合適不過了。
四 IO密集型服務器設計
(1)網絡層多線程，中間線程按照業務特色設定，同步點操做使用多線程
同步點使用多線程是該類服務器的本質特徵。在同步操做的返回時間不能由本服務器控制的前提下，本服務器所能作的也就只能是加多線程數，提供同步併發數。線程數的最優配置取決於網絡層入口併發數以及同步操做返回的時間。簡單劃分能夠網絡線程數=cpu個數/2.同步點線程數還取決於同步操做的代價，若爲廉價的cache操做，則可適當增多，若爲昂貴的db操做，則要根據能夠分配的鏈接數決定。
(2)減小人爲產生的同步點
儘可能減小訪問其餘系統使用同步接口。
(3)優化同步點
根據同步操做的特色優化: 異步/增大緩存/批量等。

五 內存操做/鎖機制/內核態用戶態切換/日誌操做
(1)內存操做
內存申請：減小內存動態分配，推薦tcmalloc
內存複製：CPU密集型，必須的內存複製：(a)網絡讀：處從內核態複製到用戶態，僅1次 (b)網絡寫：異步內存複製/用戶態到內核態 ，僅2次
                    IO密集型，內存複製非關鍵點。
(2)鎖機制 CPU密集型：儘可能無鎖. IO密集型: 非關鍵點
(3)內核態用戶態切換
兩類服務器均相同，儘可能減小內核態/用戶態互相切換：每次調用系統調用盡量讀取更多字符/僅可能減小沒必要要的系統調用（去除沒必要要的調用/經過緩存機制減小調用次數）。
(4)日誌操做 略
六 進程vs線程vs協程
進程和線程（略）
協程：和進程/線程這種cpu調度單元不一樣，它更可能是線程內對象之間一種調度理念的優化。協程對象有本身的堆棧，能夠經過直接跳轉直接轉換執行點，減小了內存尋址操做。它特別適合用來優化線程內的某些基礎組件，包括：狀態機/調停者模式（或者線程內隊列）。

在CPU密集型服務器的設計中，說道「線程是給那些不能將程序執行序轉換成狀態機的笨人用的」，而有了協程，咱們有了一種新的簡化編程的方法。將協程用於網絡層，能夠手動實現相似select的功能，用於多對象參與的複雜中間狀態，能夠簡化編程。
但從總體性能角度看，協程則是雞肋的存在，從幾年前出現boost.Coroutine，到如今該項目中止開發，boost引入更多其餘方案asio/mpl/statechart，協程一路蹣跚。
七 總結
在當前硬件體系架構下，服務器性能的關鍵仍然是傳統的cpu/io/memory.
cpu密集型的服務器，須要最大限度充分利用全部cpu，以及儘可能少的進行內存申請/內存複製。
IO密集型服務器，須要最大限度提升io能力，爲達到該目的，能夠在非同步線程犧牲對cpu的利用率/犧牲對memory的高效使用，一切爲提升io併發能力服務。
八  後記
特別感謝張傑同窗代替我編譯探測程序代碼，讓我有時間碼點文字。