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

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

基于HTTP協議我們可能發現我們要解決兩點問題：

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

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

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

第二，Session狀態的保持和遷移。

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

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

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

SQLServer是把session保存在數據庫中。同樣能達到目的。

Custom自定制的存儲方案，我們自己寫當然能夠實現。

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

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

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

否則各個應用服務器拿到的session還是不一樣的。