經常使用服務器模型(轉載)

 1）  迭代性服務器

        迭代性服務器，在開源社區的表明之做是Apache Web服務器。該模型中，存在惟一的偵聽進程，偵聽進程accept新的連接以後，經過fork的方式，派生出一個新的進程來爲這個請求進行專門的服務，直至請求所有處理完成，被fork的進程也會自動退出，在服務過程當中被佔用的各類資源得以釋放。

        這種服務器開發模型的優缺點分別以下：

        優勢：

         　　開發流程比較清晰，對開發人員的要求比較低，對於內存泄漏、句柄未釋放等各類請求服務器開發比較頭疼的問題，隨着業務進程自動銷燬，所有都一了百了；

         缺點：

              每接受一次請求，均須要fork一個新的子進程，效率比較低，主要受限於機器fork進程的效率，不適合處理併發量比較大的狀況； 

         使用場景：

                  迭代模型比較適合於請求併發量小，每次請求處理時間相對比較耗時的業務（業務處理流程比較複雜），例如處理圖片上傳等時耗比較長的業務。

           2）併發性服務器

          併發性服務器，顧名思義，同一時刻能夠接受多個客戶端的請求消息。這種模型的從實現方式來分主要有兩種類型：多線程和多進程模型。在併發服務模型中，由主進程socket的listen等操做，而後fork出多個業務處理進程，每一個業務進程在該socket上面進行accept操做，爭相去獲取該請求的處理權（其實是由操做系統來進行客戶端的請求分配一個正在等待的其中一個業務進程）。業務進程接收到客戶端處理請求以後，開始進行具體的業務流程處理，待業務流程處理結束以後，又從新回到accept的位置，等待處理下一個客戶端請求，按照這個流程周而復始，循環執行；

           這種服務器開發模型的優缺點分別以下：

           優勢：

                    併發服務模型，併發處理客戶端請求的能力有了很大的提高，也是在中度併發請求量的場景下比較經常使用的服務器模型； 

            優化改進版：

                   在實際開發過程當中，可能會遇到業務進程發生內存泄漏、句柄泄漏、段錯錯誤等不容易分析出來的場景，這種狀況下，能夠設定每一個業務進程只處理多少次，到達指定的次數以後，自動銷燬釋放，父進程不斷檢測子進程的個數，當子進程的個數不符合需求時，由父進程從新fork出新的子進程來處理新的請求；

 

            3）  異步服務器

           歸結命名爲異步服務器模型，主要特徵在於，該類服務器模型均使用網絡異步模型select或者epoll等，使用異步網絡模型的優點在於：單個進程（線程）能夠同時等待多個socket的讀寫事件，大大的提升了網絡操做的效率，目前來說，網絡異步模型尤爲是epoll基本已是高性能服務性的標配。開源社區使用網絡異步模型典型有：Memcached（基於libevent）、Redis、Nginx等開源力做。

使用網絡異步事件的典型是採用多線程模型，在單進程中，存在一個專門的偵聽線程，負責整個服務中網絡鏈接、可讀、可寫等事件的偵聽，例如存在可讀事件時，通知給具體的業務處理線程來進行處理。（參見文章的線程模型圖片，http://www.iteye.com/topic/344172）。

           採用這種網絡模型的優缺點分別爲：

          優勢：

                   網絡操做高效，能夠快速的處理海量網絡請求的狀況；

          缺點：

                   a）系統複雜度比較高，對開發人員的開發功底要求比較高；

                   b）業務代碼與網絡操做網絡耦合在一塊兒，一處出現問題，會致使滿盤皆輸；