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 在這點上使用了“共享記憶體 ”，這個記憶體拷貝也省略了。

等等。

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

[開發前準備]

在進行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 在這點上使用了“共享記憶體 ”，這個記憶體拷貝也省略了。