關於併發你真的瞭解嗎？（二）

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

 前言：對於一些公司來講可能會遇到一些併發處理的問題，本文有可能會對您有所幫助。

對於一臺服務器的公司來講若是您有提高併發處理的需求可是又不想增長服務器數量的話，如下方法有可能對您有所幫助：

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共享機制。

設置步驟

一、 肯定StateServer服務器。若是隻有一臺WEB服務器，可指定當前服務器爲StateServer服務器。若是存在多臺服務器集羣，可指定集羣中的一臺符合較輕的服務器做爲StateServer服務器。

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

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

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

在彈出的【屬性】窗口中，將【啓動方式】改成「自動」，而後點擊【啓動】按紐啓動服務

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

注意事項

一、 Session中保存的自定義對象必須顯示標記爲可序列化「[serializable]」。若是未顯示標記爲可序列化，則在訪問頁面時會報錯。

二、 StateServer服務器必須爲Windows Server操做系統，如Windows Server 2003或Windows Server 2008。

 本文版權歸做者 心灬無痕（博文地址：http://www.cnblogs.com/xinwuhen/）全部，歡迎轉載和商用，請在文章頁面明顯位置給出原文連接並保留此段聲明，不然保留追究法律責任的權利，其餘事項，可留言諮詢。