1：HTTP重定向
所謂HTTP重定向，就是通過修改HTTP響應頭中的Location標識爲新的URL，然後返回給客戶端，讓客戶端重新根據這個Location標識的URL去做新的請求。
這是一種最簡單、也是最輕量級的負載均衡實現方案，使用asp.net，我們可以這樣來實現，比如在主站www.yourdomain.com中，我們在默認主頁如下編碼：
static string[] servers = { };protected void Page_Load(object sender, EventArgs
e){ Response.Redirect(servers[DateTime.Now.Millisecond % 2]);} |
在上面的代碼中，Response.Redirect實際爲http頭返回狀態碼302，這是爲了告訴瀏覽器，請到Location中去拿URL，並且去到這個新的URL去做請求。當然，我們也可以採用最原始的方法來代替Redirect方法：
Response.Status = "302 Found";Response.StatusCode = 302;Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]); |
使用HttpWatch監視，我們對www.yourdomain.com請求，得到：
可以清晰的看到第一次請求返回的302，然後轉發到新的地址，得到狀態碼200。
以上方法是在客戶端的重定向，即瀏覽器請求了兩次，一次是到主服務器，第二次是到Location中指定的服務器上去請求。
HTTP重定向的方式非常依賴於主站的處理能力，它的性能瓶頸也是來自於IIS對於接受請求->asp.net處理首頁動態程序->返回帶有特定頭請求，是的，它不能突破自身的性能瓶頸，比如，在我的破測試機上，我得到的吞吐率爲：
好在IIS自身已經支持重定向（查閱http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx），這更進一步省略了我們自己寫代碼實現重定向，省略運行ASP.NET代碼帶來的性能損耗。
2：varnish實現的反向代理負載均衡
另外一種思路是使用反向代理服務器的負載均衡功能，上篇當中介紹的varnish就支持這樣的功能，查看配置文件：
backend web1 { .host = "192.168.0.77"; .port = "8081"; }backend web2 { .host = "192.168.0.77"; .port = "8082";}director lb round-robin { { .backend = web1; } { .backend = web2; }} sub vcl_recv { set req.backend = lb; return (pass); } |
在該配置文件中，我們部署了兩臺WEB服務器，當然，爲了簡單期間，我這裏是使用了同一臺服務器的兩個端口。在vcl_recv函數中，varnish定義了負載均衡。
運行varnish之，我們會發現請求被轉發到後臺服務器了。
3：其它方案
1：DNS負載均衡，通過增加域名A記錄來讓DNS服務器實現負載均衡。好處是幾乎不會碰到性能問題。缺點：要求每個WEB服務器必須有外網地址。一旦某臺服務器崩潰，不能及時讓DNS修改生效。不能定義自己的轉發策略；
2：IP負載均衡，有LVS-NAT，採用iptables，對LINUX內核操作，性能相對於反向代理服務器並沒有質的飛躍；IP負載均衡仍舊需要轉發請求給實際服務器，同時需要轉發實際服務器的響應給用戶，所以，它的性能瓶頸來自於NAT服務器的性能及網絡帶寬；
3：直接路由，有LVS-DR，工作在數據鏈路層（第二層），要求所有WEB服務器接入外網；負載均衡器負責轉發請求給實際服務器，但是它通過修改數據包中的MAC地址，能夠做到讓實際服務器的響應直接返回給用戶，而不用通過負載均衡器，這當然進一步提升了負載均衡的效率；
4：IP隧道，有LVS-TUN，用於不同機房（即不同WAN網段）的負載均衡，原理同LVS-DR；
