簡易負載平衡的實現-續《幾百元搞定大型網站》

來源:互聯網
上載者:User

 

        上回說到了一種通過增加網站數量,人為的分散單網站的負載,同時增加總體頻寬的方法,其實裡面有很多疑問,我就在後面一一談論自己的想法。           首先,兩個主站的互為備份屬於物理層面上的,並且真正的活躍的主站只能有一個,也就是我們網站A記錄對應的主機,在保證兩點的資料一致的情況下,當一個節點出現問題,我們可以手工的修改A記錄,將主站切換到另一個節點,但這需要時間,也就是網域名稱解析同步的時間。這種結構對可預測的宕機是很有用的。但如果要實現智能負載平衡還需DNS伺服器的參與,這點是虛機主機和網域名稱服務 (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 網站上一定會將這個理論付諸於實踐,歡迎大家關注。

本文出自 “專註資訊系統一體化建設” 部落格,謝絕轉載!

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.