• <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 日需博客 閱讀(392) 評論(0)  編輯 收藏 引用 所屬分類: 技術文章轉載
            亚洲精品WWW久久久久久| 久久精品国产91久久综合麻豆自制 | 国产农村妇女毛片精品久久| 国产精品VIDEOSSEX久久发布| 久久精品无码一区二区日韩AV| 久久国产欧美日韩精品免费| 久久99精品国产麻豆| 精品久久久久久久中文字幕| 亚洲国产精品无码久久一区二区 | 精品久久久中文字幕人妻| 99国产精品久久久久久久成人热| 色欲综合久久躁天天躁| 久久久女人与动物群交毛片| 人人狠狠综合久久亚洲高清| 丁香狠狠色婷婷久久综合| 色综合合久久天天给综看| 国产精品久久久久久| 久久99精品国产麻豆宅宅| 狠狠久久综合伊人不卡| 久久99国产精品久久| 伊人久久精品无码av一区| 伊人色综合久久天天人守人婷| 国产精品激情综合久久| 青青草原综合久久大伊人精品| 久久人人爽人人爽人人AV东京热 | 久久大香香蕉国产| 中文字幕无码精品亚洲资源网久久| 91亚洲国产成人久久精品| 久久国产成人精品麻豆| 99久久国产综合精品麻豆| 欧洲成人午夜精品无码区久久| 久久久久久国产a免费观看黄色大片| 久久婷婷色综合一区二区| 国产精品伦理久久久久久| 久久91精品久久91综合| 国产高清国内精品福利99久久| 国产精品99久久99久久久| 久久最近最新中文字幕大全 | 亚洲精品WWW久久久久久| 无码8090精品久久一区| 国产精品乱码久久久久久软件|