在ASP.NET站點里面實現(xiàn)負載均衡，其實和其他WEB的實現(xiàn)方式基本類似。同樣我們需要負載均衡器，之后是對會話狀態(tài)的設(shè)置，我們要保證會話寶石和遷移正常。其中需要的配置并不是很多，在這里，我們制作一個簡要介紹。

ASP.NET站點中做負載均衡：

基于HTTP協(xié)議我們可能發(fā)現(xiàn)我們要解決兩點問題：

***，做到負載均衡，我們需要一個負載均衡器。

可以通過DNS輪詢來做，在DNS服務(wù)器上配置為每次對我們做負載均衡的同一主機名的DNS查詢得到不同的IP地址。這樣的好處是配置簡單投入較小，缺點是瀏覽器訪問各個服務(wù)器的機會是均等的，不能根據(jù)服務(wù)器的負載程度自動把請求路由到負載較小的服務(wù)器。

可以通過專用的負載均衡設(shè)備，通過監(jiān)測后臺數(shù)臺服務(wù)器的負載情況，自動把HTTP請求轉(zhuǎn)發(fā)到負載較輕的服務(wù)器。另外必須監(jiān)測后臺服務(wù)器的IIS負載情況，而不是整臺服務(wù)器的CPU負載。同時可能需要在負載均衡器和后臺服務(wù)應(yīng)用之間建立心跳連接，以避免出現(xiàn)某臺服務(wù)器IIS進程或者其中跑的應(yīng)用已經(jīng)down掉，負載均衡器反而監(jiān)測到這臺服務(wù)器的負載最小而把大量請求轉(zhuǎn)發(fā)的這臺服務(wù)器，達到相反的效果。

第二，Session狀態(tài)的保持和遷移。

由于HTTP協(xié)議的無狀態(tài)性，我們一般是在Session中保存客戶端的一些狀態(tài)數(shù)據(jù)，負載均衡之后，前后兩次HTTP請求所到達的服務(wù)器可能不是同一臺，這就造成可能出現(xiàn)這樣的情況，前一此請求處理中設(shè)置的session在第二次請求中變得不可用了，造成應(yīng)用程序出錯。所以我們要把 session跟隨遷移。實現(xiàn)的方法就是session的統(tǒng)一存儲和服務(wù)器間共享。

在ASP.NET中服務(wù)器保存session有五種方式，Off不說了，InProc是保存在服務(wù)器進程的內(nèi)存中，顯然不能滿足要求。另外兩種能夠滿足：

StateServer是把session保存在專門的狀態(tài)服務(wù)器中。這樣各臺服務(wù)器都存取同一個StateServer，達到共享的目的。

SQLServer是把session保存在數(shù)據(jù)庫中。同樣能達到目的。

Custom自定制的存儲方案，我們自己寫當然能夠?qū)崿F(xiàn)。

比較一下，Custom這種自己實現(xiàn)比較麻煩一般不用，SQLServer可以利用數(shù)據(jù)庫的cluster達到高性能和高可用性的目的，StateServer當然也可以通過手段達到高可用性，不過似乎不能實現(xiàn)集群所以性能也有所限制。

另外如果要做負載均衡在StateServer和SQLServer中配置session時，必須在web.config中重寫 machineKey節(jié)點：

<machineKey 
validationKey="1234567890123456789012345678901234567890AAAAAAAAAA" 
decryptionKey="123456789012345678901234567890123456789012345678" 
validation="SHA1" 
decryption="Auto" 
/> 

否則各個應(yīng)用服務(wù)器拿到的session還是不一樣的。