• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            流量統計:
            Rixu Blog (日需博客)
            日需博客,每日必需來踩踩哦..
            posts - 108,comments - 54,trackbacks - 0

                目前網站架構一般分成負載均衡層、WEB層和數據庫層,我其實一般還會多加一層,即文件服務器層,這樣我們在后面的討論過程中,我們可以依次對這四層進行討論;這里為了更具有說服力,我將用三個并發較大的生產環境來說明下,一個是我現在維護的電子商務網站(并發最大值2000,日PV500萬左右,此并發并不是總這么高的,只是最高峰是有2900,下面的網站類似)、我的一拍網網站(并發最大值500,日PV50萬左右)、以前維護的大型CDN廣告網站(并發最大值5000,日PV5000萬左右)。

            首先說下負載均衡層,我們熟悉的硬件/軟件技術有F5/LVS、HAProxy,還有Nginx,它們的性能都是非常優異的,且不說F5的抗并發能力,LVS現在在全世界范圍內的應用,而且淘寶現在升級架構,也將LVS取代了F5,HAProxy可能大家不是特別熟悉,但它確實在生產環境下表現優異,強大的吞吐能力,穩定性比之硬件過尤不及,再說下Nginx,我是將Nginx/HAProxy+Keepalived架構用于了各種生產環境中的,經過長時間的線上觀察,發現Nginx/HAProxy作為負載均衡器/反向代理也很穩定,就算并發壓力過大,我們前面可以用F5/LVS來頂,而將Nginx作為中層代理,這樣的效果其實也不差,所以負載均衡層的壓力不能算是特別大。

            WEB層這塊壓力比較大的網站現在都換成了Nginx作為WEB應用服務器,事實上,它的抗并發能力確實超過了預期;我朋友維護的一家門戶網站,高峰期時某臺Nginx應用服務器的并發達到了一萬以上,但Nginx也很負責和穩定的提供服務,在實際的生產環境中,如果我們考慮到后端的數據庫服務時,一萬并發應該也算是一個比較大的數值了;另外,Linux集群有一個優勢,就是它的高擴展性,就算我們的網站的并發有一萬以上,我們后端的WEB服務是Apache,我們多加幾臺Apache服務器即可,在實際的線上維護時,我們發現,高峰期間,實際上每臺WEB的并發并不算是特別大,所以網站的壓力在這一層我們也能通過技術手段加以克服。

            再說下文件服務器層,由于網站的后期宣傳策話,名氣也越來越大,PV值也越來越高,原先的DRBD+Heartbeat+NFS(這個其實也只是單NFS,只不過我們利用DRBD來保證NFS的高可用而已)已經越來越頂不住壓力了,這個時候我們想到了分布式文件系統,我測試的的是MooseFS,在內網測試了很長時間還是沒敢用到生產環境下面,googel的分布式文件系統還是很成熟的,推薦大家學習;最后還是用采用以前的CDN傳統的方法解決這個問題,即用了squid反向代理加速器來解決小文件過多的問題,Nginx強大的正則處理分發能力,也讓后端的NFS壓力變得很小;另外,我還用采用域名的分散策略例如使用pics.xxx.com/pdf.xxx.com...來區分標記為a或b的一系列文件,這些文件存儲的時候,依然按照標記,存到pics或pdf的服務器上。這個策略將區分機器的任務交由dns服務器來執行,擴容時會相應輕松。這需要web項目初期就規劃好這些東東,后期才轉用域名策略的成本比較高甚至不可以實現,大家可以注意下,其實這一層如果網站是專業的圖片服務器網站時壓力還是很大的,我們需要在這個上面投入足夠多的硬件資源。

            最后說下數據庫層的壓力,我覺得網站的PV和并發上去以后,數據庫這塊的壓力是最大的,CDN大型廣告網站我們用的是oracle RAC方案,它保證了數據的高可用性,當然了價格也是非常昂貴的(如果使用高配置的PC服務器,Oracle一般按照CPU個數收費);那么免費的MySQL數據庫,面對這種并發壓力大的情況,又用哪些方法呢?首先,我們說下傳統的MySQL主從方案,配置簡單,單機MySQL優化做好事性能也不弱,如果這種架構解決不了數據庫的壓力情況,我們可以考慮以下幾種方案:

            常規復制架構--Master-slaves,是由一個Master復制到一個或多個Salve的架構模式,主要用于讀壓力大的應用數據庫端廉價擴展解決方案,讀寫分離,Master主要負責寫方面的壓力。級聯復制架構,即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大,而配置一層二級 Slaves,很容易解決Master端因為附屬slave太多而成為瓶勁的風險。

            Dual Master與級聯復制結合架構,即Master-Master-Slaves,最大的好處是既可以避免主Master的寫操作受到Slave集群的復制帶來的影響,而且保證了主Master的單點故障。

            MySQL的數據庫切分,我們可以通過數據切恰好技術將一個大的MySQL Server切分成多個小的MySQL Server,既解了寫入性能瓶頸問題,同時也一次提升了整個數據庫集群的擴展性,從而解決了數據庫壓力過大的問題,這個現在也是我在生產環境中比較推薦的做法之一。

            事實上我也跟許多系統維護人員和MySQL DBA線下交流過,現在生產環境下用得比較多的MySQL架構有:一、MySQL一主一從(這個優化得好,百多萬PV的網站完全沒問題);二、DRBD+Heartbeat+MySQL(MySQL官方推薦);三、MySQL一主多從,讀寫分離,LVS或HAProxy作讀的LB。

            這段時間一直跟老男孩前輩交流千萬級PV的網站架構,系統架構其實是件藝術活兒,我們應該盡量做到以下幾點:一、保證高可用;二、保證高可擴展性;三、盡量把用戶往外面推(老男孩語),足矣。

            Logo
            作者:Gezidan
            出處:http://www.rixu.net    
            本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。
            本文轉載自 http://andrewyu.blog.51cto.com/1604432/612032
            posted on 2011-10-08 09:08 日需博客 閱讀(388) 評論(0)  編輯 收藏 引用 所屬分類: 技術文章轉載
            日韩亚洲国产综合久久久| 久久精品视频网| 亚洲午夜无码久久久久| 奇米影视7777久久精品| 国产韩国精品一区二区三区久久| 色综合久久中文综合网| 欧美一级久久久久久久大片| 亚洲中文字幕无码久久综合网| 精品亚洲综合久久中文字幕| 午夜精品久久久久9999高清| 精品久久久久久无码专区不卡| 欧美激情精品久久久久久久九九九| 久久久无码精品亚洲日韩京东传媒| www性久久久com| 伊人久久大香线蕉AV色婷婷色| 久久99国产精品久久99| 亚洲国产精品无码久久一区二区 | 久久99精品久久久久久久不卡| 久久精品国产一区二区电影| 国产情侣久久久久aⅴ免费| 伊人伊成久久人综合网777| 亚洲国产精品婷婷久久| jizzjizz国产精品久久| 亚洲精品国产字幕久久不卡| 国产精品成人久久久| 精品国产91久久久久久久a| 国产精品久久久久9999高清| 麻豆成人久久精品二区三区免费| 亚洲精品美女久久久久99小说 | A级毛片无码久久精品免费| 久久精品亚洲男人的天堂| 日本久久久精品中文字幕| 国产精品99精品久久免费| 久久久久久人妻无码| 中文字幕人妻色偷偷久久 | www性久久久com| 色婷婷综合久久久久中文| 亚洲综合熟女久久久30p| 久久精品蜜芽亚洲国产AV| 久久精品无码一区二区无码| 97久久香蕉国产线看观看|