linux伺服器開發淺談

[開發前準備]

在進行linux伺服器開發之前，必須很清楚地瞭解所開發的對象需要考慮的相關問題
比如：
功能架構：提供服務的模組體繫結構
穩定性：伺服器的出core率，記憶體泄露情況
效能：請求與返回的速度與正確性
負載能力：能同時訪問的最大數量和頻度

根據不同伺服器對象的環境和應用，伺服器開發的對應手段相差甚遠。比如就用戶端連線時間較短卻又比較頻繁的伺服器（例如HTTP伺服器）而言，
在可選的伺服器結構中，預先派生進/線程的結構就要比並髮式結構高效

總之，在程式開發伺服器之前，必須進行完整的伺服器開發需求分析，否則一旦你的伺服器開發完成而因為效率或者其他某項事物不能滿足你的客戶，那麼很有可能失敗！

[伺服器讓我明白了這件事情]

伺服器一般在後台運行，與用戶端的互動通過請求和返回兩種方式進行通訊。
以epoll為例，一個epoll開發的伺服器程式，等待著一百萬的用戶端使用者的請求，輪詢觀察某個時刻是否有用戶端發來的請求；排隊依次處理髮來的請求，並將結果返回給
用戶端應用程式。
涉及到幾個技術問題：
第一，用戶端訪問進入epoll輪詢隊列的優先順序是否需要控制。比如甲是我們的vip白金使用者，那麼，我始終先處理甲發來的請求，不然白金使用者要生氣的。
第二，極大可能程度上最佳化處理請求的速度，這是伺服器設計的核心業務。
第三，如果用戶端請求了這樣一個事情：我需要看這一百年來某企業所有的資訊，那麼我想這個資訊量是很大的，也就是現在很熱門的大資料大檔案傳輸問題，如何快速
將服務端的這些結果傳給用戶端，在頻寬允許的情況下當然越快越好！這裡會有很多處理措施，當然你可以打成一個包直接扔過去，但是這樣是愚蠢的，像蝸牛背著一個
重殼在挪動，使用者可等不了這麼久；聰明的做法當然很多，根據你的實際需要，比如，你可以壓縮，你可以分批，等等。
等等，其實伺服器的整個開發，每個細節都決定了你的伺服器的成敗優劣。在開發linux伺服器的項目後，我個人決定，一個讓你的伺服器變得強大的很重要的因素是——
——你不願意放棄任何一個可以挺高效能的因素，即使是快0.01ms或者少傳1bt的資料！

[流行的伺服器模型]

1 PPC/TPC 模型

這兩種模型思想類似，就是讓每一個到來的串連一邊自己做事去，別再來煩我 。只是 PPC 是為它開了一個進程，而 TPC 開了一個線程。可是別煩我是有代價的，
它要時間和空間啊，串連多了之後，那麼多的進程 / 線程切換，這開銷就上來了；因此這類模型能接受的最大串連數都不會高，一般在幾百個左右。

2 select 模型

2.1. 最大並發數限制，因為一個進程所開啟的 FD （檔案描述符）是有限制的 由 FD_SETSIZE 設定，預設值是 1024/2048 ，因此 Select 模型的最大並發數就被相應限制了。
自己改改這個 FD_SETSIZE ？想法雖好，可是先看看下面吧 …

2.2. 效率問題， select 每次調用都會線性掃描全部的 FD 集合，這樣效率就會呈現線性下降，把 FD_SETSIZE 改大的後果就是，大家都慢慢來，什嗎？都逾時了？？！！

2.3. 核心 / 使用者空間 記憶體拷貝問題，如何讓核心把 FD 訊息通知給使用者空間呢？在這個問題上 select 採取了記憶體拷貝方法。

3 poll 模型

基本上效率和 select 是相同的， select 缺點的 2 和 3 它都沒有改掉。

4 Epoll 模型

把其他模型逐個批判了一下，再來看看 Epoll 的改進之處吧，其實把 select 的缺點反過來那就是 Epoll 的優點了。

3.1. Epoll 沒有最大並發串連的限制，上限是最大可以開啟檔案的數目，這個數字一般遠大於 2048, 一般來說這個數目和系統記憶體關係很大 ，
具體數目可以 cat /proc/sys/fs/file-max 察看。

3.2. 效率提升， Epoll 最大的優點就在於它只管你“活躍”的串連 ，而跟串連總數無關，因此在實際的網路環境中， Epoll 的效率就會遠遠高於 select 和 poll 。

3.3. 記憶體拷貝， Epoll 在這點上使用了“共用記憶體 ”，這個記憶體拷貝也省略了。

等等。

在開發你的伺服器之前，應根據自己的業務需求和實際情況，恰當地選擇伺服器的模型，這對這個伺服器的功能效率都是具有很重要的意義的。