關於並發你真的了解嗎？（一）

本文僅代表帶個人觀點及理解，本人只是一個編程小菜鳥，如果有不對的地方。請大佬輕噴！

前言：對於很多工作時間短或者編程經驗不足的程序員來說，大多數會覺得並發這個詞離自己太遙遠，之所以知道並發也不過是因為受那些技術大佬成天討論並發等問題耳濡目染罷了。更有甚者，一些所謂的"項目經理"。一邊侃侃而談"大數據"，"高並發處理"等等高級問題，一邊理所當然的寫出Select * 或者是毫無規範性的性能極差的代碼。當然這也跟國內的大環境有一定的關系，導致很多程序員僅僅只想滿足功能完成任務即可。實際上並發的處理是和我們日常工作息息相關的無論初級，中級，高級程序員。本文將從整體架構和日常工作，兩個角度來分別講解關於並發的兩三事。只想了解日常工作中如何規範化的童鞋下拉到自己關心的部分查看閱讀。

說道並發，首先你需要了解幾個詞語：

IIS連接數、IIS並發連接數、IIS最大並發工作線程數、應用程序池的隊列長度、最大工作進程數調試

IIS連接數

一般購買過虛擬主機的朋友都熟悉購買時，會限制IIS連接數，這邊先從普通不懂代碼用戶角度理解IIS連接數

顧名思義即為IIS服務器可以同時容納客戶請求的最高連接數，準確的說應該叫"IIS限制連接數"

這邊客戶請求的連接內容包括：

1、網站html請求，html中的圖片資源，html中的腳本資源，其他需要連接下載的資源等等,任何一個資源的請求即一次連接（雖然有的資源請求連接響應很快）

2、如果網頁采用框架（框架內部嵌套網頁請求），那麽一個框架即一次連接

3、如果網頁彈出窗口（窗口內部嵌套網頁請求），那麽一個窗口一個連接

限制連接數即為虛擬主機供應公開的IIS連接數標準，如果購買的IIS連接數為50,那麽我們不得不考慮網站的內容框架和訪問量

如果網站圖片夠多，彈窗窗口隨意（可能連時間選擇框、簡單條件篩選框也用彈出新窗口），加上不得已的打開新頁面瀏覽內容，那麽僅僅能容忍10個人同時操作也很正常，我不會把這個操作描述為很多網站說的"10同時在線"，這很容易讓人誤解，在用戶的一次請求（表面上可能是刷新一次網頁，實際上內部請求不止一次，事實上很少只有一次）都完成得到服務器響應完畢之後，連接全部會被釋放，當然在你看到展示的頁面之前，內部嵌套如果有請求圖片等連接請求，連接會早早的被釋放

事實上，很多企業門戶網站訪問量低的驚人，IIS連接數為50也是綽綽有余了

IIS並發連接數

其實，普通用戶常說的"IIS鏈接數"就是這邊的"最大並發連接數" ，我這邊IIS默認最大並發連接數為：4294967295，這是一個很驚人的數字，難道這代表著網站能具有並發執行連接數為4294967295的能力？

這邊我做幾個假設：

1、很多虛擬主機供應商所說的無並發連接數限制真的成立嗎？

2、每個連接的處理，IIS都會開啟一個線程去處理，假設這個處理方式成立，那麽4294967295個並發連接請求來了是否IIS會立即啟動4294967295個線程去處理？

對於1：很顯然不成立，最大並發連接數的設置絕對有上限

對於2： 這是很多朋友的誤區，假設4294967295並發連接同時來了，IIS不會立即啟動4294967295個線程去處理，因為這不現實，對於處理連接，IIS是有" 最大並發工作線程數 "限制的，這是我下面要介紹的，我從一些資料上查閱到， 該數字跟操作系統 相關，win7 系統的IIS的值是10（或者其他不確定），VS2012自帶的IIS Express的值是80。對於w indows 服務器版本的系統 的具體值不清楚，即4294967295個並發連接來了後，（這邊以win7下的10為例），iis第一時間只能啟動10個工作線程去處理，那麽其他42949672 85 必須排隊，排隊對用戶的體驗來說就是網頁正在加載，但是什麽都不顯示，然後此時購買了據虛擬主機供應商所說的無並發連接數限制的客戶就要開始狂暴了，為何購買了所謂的"無限並發連接數"，還是會一直在加載的情況，我只能說這就是IIS處理能力有限的問題了

當然服務器沒有直接返回" HTTP Error 503. The service is unavailable."應該也算是一些你花更多錢的安慰吧，因為你只購買了IIS連接數為50的話，那麽第50+1個連接請求操作得到的就直接是"HTTP Error 503. The service is unavailable."了

另外，如果web服務器的硬件設備夠爽朗（牛逼），那麽IIS的工作線程也會處理的更快，那麽響應的用戶等待的時間也會更短（前提是你的IIS連接數夠大哦，否則就直接503了哦）

總的來說，最大並發連接數，影響了排隊的數量，

很多時候需要我們評估自己的網站的最大並發連接數，然後來進行設置最佳數量

IIS最大並發工作線程數

這個在上面有所涉及，簡單的說就是IIS在並發連接請求過來時的處理機制，它會更機智的以某個數量級為單位來分批處理，讓沒有處理連接請求排隊等待，用戶瀏覽器中對於排隊等待的響應就是"正在加載"，這比頁面直接顯示" HTTP Error 503. The service is unavailable. "更加能讓人接受，但是切勿氣急敗壞的怒點刷新按鈕，因為點的越多，你的請求在排隊隊伍中越靠後。

當然很多朋友會說，為什麽我有時候第一次刷不出來，重新多刷一次內容就出來了？

1、頁面腳本哪個地方下載或者處理出了問題，導致頁面顯示異常或者直接不顯示

2、你重新刷新的那個秒級別的操作，web服務器更快速的已經處理好了其他隊列的請求或者他人放棄了對web服務器連接請求的操作

3、路由或者寬帶網絡運營商問題（不穩定）

4、瀏覽器或者本身電腦問題

那麽現在問題來了，最大並發連接數，影響了排隊的數量，那麽有沒有進步影響排隊數量的設置? 有的：隊列長度

隊列長度

假設最大連接數設置為100，1000個並發連接請求過來了，首先900直接返回給客戶"HTTP Error 503. The service is unavailable."

然後IIS先啟動（假設最大並發工作線程數為10）10個線程處理請求，其他90個進入排隊狀態，如果此時如下操作：

找到網站的所屬應用程序池，"右擊高級設置"->"常規"->"列隊長度"，設置為20

那麽實際情況又會變成什麽樣子呢？只會有20個進入排隊狀態了，70（90-20）個請求也會立刻返回"HTTP Error 503. The service is unavailable"

iis默認隊列長度設置是1000，範圍在10-65535 之間

最大工作進程數

應用程序池一般默認最大工作進程數為1，可以找到網站的所屬應用程序池，"右擊高級設置"->"進程模型"->"最大工作進程數" 來修改設置

如果這個值大於 1，那麽當有連接請求時會啟動多個新的工作進程實例，可啟動的最多進程數為您所指定的最大工作進程數，後續更多的請求將以循環的方式發送至工作進程，這個每個工作進程都能承擔負載一些連接請求，當然是以消耗cpu等硬件做代價，這是值得的，如果web服務器cpu使用率很低但是又需要更高效的處理並發連接請求，為何不這麽做呢？

如果網站中用到了依賴進程的Session和Cache等對象，則不能保存在服務器內存中，存儲方式選用StateServer或者SQLServer會更好，另外多個工作進程切換時會有上下文復制，這也是資源消耗更多地方

最大工作進程數調試

最大工作進程數的設置方法：（拷貝）按照每工作進程能承載30個並發的原則來確定應用程序池的最大工作進程數。同時要註意，每個工作進程大約會占用200M左右的系統內存，在設置最大工作進程數的時候，要主要最大工作進程數與200M的乘積不要超過系統最大可用內存數。一般情況下，建議按照每次增加5個工作進程數的方式對最大工作進程數進行調整，調整完後對網站觀察一段時間，如依然無法滿足要求，再繼續增加5個工作進程數。

關於並發你真的了解嗎？（二）

對於一臺服務器的公司來說如果您有提升並發處理的需求但是又不想增加服務器數量的話，以下方法有可能對您有所幫助：

1.如果web服務器cpu使用率很低但是又需要更高效的處理並發連接請求，您可以嘗試設置最大工作進程數。

IIS作為Windows平臺下Asp.Net網站發布的默認WEB服務器，在性能上是提供了比較大的彈性和可伸縮性，通過應用程序池工作進程數的設置，可以支持從幾十到上萬並發數量的訪問。

在主流的主機上，每個應用程序池的單一工作進程，能夠大約承受30-50個左右的並發，如果超出此並發數量，可能會出現IIS無法響應、或響應時間明顯變長的問題。通過合理設置應用程序池的最大工作進程數，可顯著提高IIS應對高並發的能力，減少網站響應時間。（具體設置方式可詳見上一篇文章《關於並發你真的了解嗎？（一）》博客園地址：http://www.cnblogs.com/xinwuhen/p/7049093.html）

2.建議使用 InProc 的Session保存機制

3.合理的資源回收機制：大多數應用系統都存在工作時間使用量高、非工作時間使用量低的情況，針對這種現象，在系統非忙時應合理的釋放操作系統資源，因此，應合理設置應用程序池的【限制超時】和【回收時間間隔】屬性。

4.程序優化（詳見《關於並發你真的了解嗎？（三）》）

5.數據庫操作優化（詳見《關於並發你真的了解嗎？（三）》）

多服務器，對於多服務器的公司來說。以下方式可能對您有所幫助：

1.對於多臺服務器來說，首先也要滿足單獨服務器優化配置。上面有講述，這裏需要註意對於多服務器Session的保存機制可以使用其他的方式下文有重點介紹。

2.您可能會遇到，某一臺或者多臺服務器已經超過了並發處理量。而其他服務器卻還有很富余的並發處理能力的情況。

此種情況您可能需要分流操作，我知道的有三種分流：

2.1，集群 - 將並發請求分配到不同的服務器上，可以是業務服務器，也可以是數據庫服務器。集群技術：多臺服務器應看作為一個服務集群而不是單一的個體服務器。群集技術是使單個服務器實現物理和程序上的連接，並對服務器之間的通訊進行協調，以使它們能夠執行共同的任務。即便某一臺服務器停止運行，一個由進程臺調用的故障應急程序會自動將該服務器的工作負荷轉移至另一臺服務器，以保證提供持續不斷的服務。除故障應急程序外，某些形似的群集也使用負載平衡功能，該功能可使計算負載在聯網的計算機間得以分配。

2.2，分布式 - 分布式是把單次請求的多項業務邏輯分配到多個服務器上，這樣可以同步處理很多邏輯，一般使用與特別復雜的業務請求。分布式系統（distributed system）是建立在網絡之上的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。因此，網絡和分布式系統之間的區別更多的在於高層軟件（特別是操作系統），而不是硬件。內聚性是指每一個數據庫分布節點高度自治，有本地的數據庫管理系統。透明性是指每一個數據庫分布節點對用戶的應用來說都是透明的，看不出是本地還是遠程。在分布式數據庫系統中，用戶感覺不到數據是分布的，即用戶不須知道關系是否分割、有無副本、數據存於哪個站點以及事務在哪個站點上執行等。

2.3，CDN - 在域名解析層面的分流，例如將華南地區的用戶請求分配到華南的服務器，華中地區的用戶請求分配到華中的服務器。

3.負載均衡設備（網上很多文章，不過多介紹）

4.使用消息隊列。隊列的使用除去了接收和發送應用程序同時執行的要求。減少並發處理數量的占用

5.緩存機制：將需要頻繁訪問的資源存放在緩存中不僅可以降低數據庫壓力而且還可以提高訪問速度進而提高用戶體驗。適程度而定必要時可以考慮緩存服務器的搭建。

6.數據庫分庫分離活躍數據 ：可以自定義規則來判定哪些訪問頻繁的數據或者重要訪問來訪問單獨庫，即"重要數據特殊對待"。從而減輕主庫壓力。並且可以提高用戶體驗。

7.降低響應時間（詳見《關於並發你真的了解嗎？（三）》），總體分為降低程序執行時間，降低數據庫操作時間。要知道即使是毫秒級的程序執行速度差異，在足夠大的並發訪問量下。差距也是異常驚人的。

8.Asp.Net的Session共享

Asp.Net提供了五種Session保存機制：

（1）Off 設置為不使用Session功能 性能 無

（2）InProc 置為將Session存儲在進程內，就是ASP中的存儲方式 性能 最好

（3）StateServer 設置為將Session存儲在獨立的狀態服務中。 性能損失10-15% 一般用於服務器集群使用

（4）SQLServer 設置將Session存儲在SQL Server中。性能損失10-20%

（5）Custom 自定制的存儲方案 性能 由實現方式決定（一般自定義方式編寫不難，但是好的性能方案很難）

在Asp.Net程序的web.config配置文件中對Session的保存方式進行設置。如果不顯示指定Session的保存方式，默認使用InProc的方式保存，即Session由提供服務的工作進程保存。

為了提高IIS對高並發的支持，可以增加應用程序池的工作進程數，IIS會根據內置的調度算法，將用戶的請求在多個工作進程間動態分配，如果搭建了服務器集群和負載均衡，則用戶請求會在多臺機器的多個工作進程間進行動態分配。在上述情況下，如果Session的保存方式依然為InProc，則用戶請求在多個工作進程間切換時可能出現Session丟失的情況，導致請求失敗或出錯。

為解決上述為，需要將Session的保存方式設置為共享即StateServer"、"SQLServer"或"Custom"方式。這三種方法中，"SQLServer"方式需要安裝獨立的SQLServer數據庫，"Custom"方式需要自行實現相應的Session存儲與檢索過程，部署起來相對復雜，相對上述兩種方式，"StateServer"方式在功能性和可實施性上最好，因此重點介紹此種Session共享機制。

設置步驟

1、 確定StateServer服務器。如果只有一臺WEB服務器，可指定當前服務器為StateServer服務器。如果存在多臺服務器集群，可指定集群中的一臺符合較輕的服務器作為StateServer服務器。

2、 修改註冊表，允許遠程訪問StateServer服務。

端口默認為42424，可根據需要進行修改，下文均以42424為例。

3、 打開【管理工具】-【服務】，找到"Asp.Net State Service"，點擊右鍵，選擇【屬性】

在彈出的【屬性】窗口中，將【啟動方式】改為"自動"，然後點擊【啟動】按紐啟動服務

4、 打開待修改網站主目錄下的web.config配置文件，搜索找到"<sessionstate>"配置節點，如果不存在配置節點，則在"<system.web>"節點下新建"<sessionstate>"配置節點，並將節點屬性修改為：
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" />
其中"tcpip=*"後的主機IP地址和端口可根據實際情況修改。修改完後保存配置文件即可。

註意事項

1、 Session中保存的自定義對象必須顯示標記為可序列化"[serializable]"。如果未顯示標記為可序列化，則在訪問頁面時會報錯。

2、 StateServer服務器必須為Windows Server操作系統，如Windows Server 2003或Windows Server 2008。

關於並發你真的了解嗎？