上回說到了一種通過增加站點數量，人爲的分散單站點的負載，同時增加總體帶寬的方法，其實裏面有很多疑問，我就在後面一一談論自己的想法。
首先，兩個主站的互爲備份屬於物理層面上的，並且真正的活躍的主站只能有一個，也就是我們站點A記錄對應的主機，在保證兩點的數據一致的情況下，當一個節點出現問題，我們可以手工的修改A記錄，將主站切換到另一個節點，但這需要時間，也就是域名解析同步的時間。這種結構對可預測的宕機是很有用的。但如果要實現智能負載均衡還需DNS服務器的參與，這點是虛機主機和域名服務商不好解決的。配過 Bind 的人都知道，可以針對來訪客戶端的IP地址判斷，應答不同的解析，實現就近訪問。我們要實現這種功能，也只能去自己手工搭建DNS服務器，或者租用能提供此種服務的DNS服務器。這是租用虛擬主機的弱點，畢竟少花錢了。
其次，針對主站間的程序同步以及數據同步，需要在程序上做很大改動，分發或者訂閱或者通過第三節點進行傳輸，這是個純技術問題。對於程序文件我們可以在程序上傳的時候進行同步上傳，這點比較容易，而數據庫這樣做就太辛苦了。如果虛擬主機供應商提供了遠程訪問數據庫的接口，我們可以在程序寫數據庫的時候，進行雙庫同時寫入，對於ASP也就是兩個Adodb.Connection連接到自己的節點和備份節點，也就是雙寫入。另外一種方法是專門寫一個同步程序，對兩個節點的數據進行一致性檢查。其實做過Exchange2007/2010的高可用項目的同學都接觸過異步日誌傳輸的概念，我們也可以將對數據表執行過的非查詢類語句進行記錄，並通過寫程序將其傳輸到另一個節點並應用。大家可能覺得這個太複雜，畢竟咱少花錢了……
再次，對於靜態內容我們將其分佈到了多個站點上進行規則性的訪問，雖然達到了負載的分配，但面對單點故障我們仍需要手工干預。那麼能不能按照負載均衡集羣的原理改善我們的站點呢？答案是肯定的。
從網站總體結構上來講，我們的主站相對於靜態內容站就相當於一個負載均衡機，由主站動態生成的HTML代碼來決定圖片從哪幾個站點來，css從哪幾個站點來等等。如果要實現容災，就必須實現節點間的互備同時必須在主站上記錄這些分站點的實時健康狀態。同樣參考DAG，假如我們有4個節點ABCD，我們可以在A上保存B的內容，B上保存C的內容，這樣當兩個不相鄰的節點出現異常時仍可以保證我們的整站資源是完整的。
關於實時健康狀態的上報，可以用一個簡簡單單的JS來搞定，在主站上可以在Application層建立一個負載計數器，根據負載情況進行智能負載分配，當遇到異常健康狀態時暫停對該節點的負載分配。
通過以上的調整，基本一個主站的手動容災和分站的智能負載均衡已經完成了，當然細節上面還有問題，比如如何使用application變量，如何傳輸sql記錄等等，以後有時間再繼續詳細闡述，歡迎大家拍磚，同時在http://www.guoerguo.com 站點上一定會將這個理論付諸於實踐，歡迎大家關注。