ASPNET站點中做負載均衡
基於HTTP協議我們可能發現我們要解決兩點問題
第一做到負載均衡我們需要一個負載均衡器
可以通過DNS輪詢來做在DNS服務器上配置為每次對我們做負載均衡的同一主機名的DNS查詢得到不同的IP地址這樣的好處是配置簡單投入較小缺點是浏覽器訪問各個服務器的機會是均等的不能根據服務器的負載程度自動把請求路由到負載較小的服務器
可以通過專用的負載均衡設備通過監測後台數台服務器的負載情況自動把HTTP請求轉發到負載較輕的服務器另外必須監測後台服務器的IIS負載情況而不是整台服務器的CPU負載同時可能需要在負載均衡器和後台服務應用之間建立心跳連接以避免出現某台服務器IIS進程或者其中跑的應用已經down掉負載均衡器反而監測到這台服務器的負載最小而把大量請求轉發的這台服務器達到相反的效果
第二Session狀態的保持和遷移
由於HTTP協議的無狀態性我們一般是在Session中保存客戶端的一些狀態數據負載均衡之後前後兩次HTTP請求所到達的服務器可能不是同一台這就造成可能出現這樣的情況前一此請求處理中設置的session在第二次請求中變得不可用了造成應用程序出錯所以我們要把session跟隨遷移實現的方法就是session的統一存儲和服務器間共享
在ASPNET中服務器保存session有五種方式Off不說了InProc是保存在服務器進程的內存中顯然不能滿足要求另外兩種能夠滿足
StateServer是把session保存在專門的狀態服務器中這樣各台服務器都存取同一個StateServer達到共享的目的
SQLServer是把session保存在數據庫中同樣能達到目的
Custom自定制的存儲方案我們自己寫當然能夠實現
比較一下Custom這種自己實現比較麻煩一般不用SQLServer可以利用數據庫的cluster達到高性能和高可用性的目的StateServer當然也可以通過手段達到高可用性不過似乎不能實現集群所以性能也有所限制
另外如果要做負載均衡在StateServer和SQLServer中配置session時必須在nfig中重寫machineKey節點
<machineKey
validationKey=AAAAAAAAAA
decryptionKey=
validation=SHA
decryption=Auto
/>
否則各個應用服務器拿到的session還是不一樣的
可能Custom方式可以自己定義存取session方式忽略machineKey這可能就不必要了因為沒有做過不多說
From:http://tw.wingwit.com/Article/program/net/201311/12775.html
