淺談千萬級PV/IP規模高性能高併發網站架構

寫得很好,推薦給大家.

轉載: 淺談千萬級PV/IP規模高性能高併發網站架構

作者: 老男孩 QQ: 31333741
BLOG:http://oldboy.blog.chinaunix.net
 
 
高併發訪問的核心原則其實就一句話“把所有的用戶訪問請求都儘量往前推”. 
 
    如果把來訪用戶比作來犯的"敵人", 我們一定要把他們擋在800裏地以外, 即不能讓他們的請求一下打到我們的指揮部(指揮部就是數據庫及分佈式存儲). 
 
    如: 能緩存在用戶電腦本地的, 就不要讓他去訪問CDN.  能緩存CDN服務器上的, 就不要讓CDN去訪問源(靜態服務器)了. 能訪問靜態服務器的, 就不要去訪問動態服務器. 以此類推: 能不訪問數據庫和存儲就一定不要去訪問數據庫和存儲. 
 
    說起來很輕鬆, 實際做起來卻不容易, 但只要稍加努力是可以做到的, Google的日獨立IP過億不也做到了麼?我們這幾千萬的PV站比起Google不是小屋見大屋了. 我們還是先從我們的小屋搭起吧!哈哈!下面內容的介紹起點是千萬級別的PV站, 也可以支持億級PV的網站架構. 
 
高性能高併發高可擴展網站架構訪問的幾個層次: 
 
有人會問, 我們老是說把用戶對業務的訪問往前推, 到底怎麼推啊?推到哪呢?下面, 老男孩就爲大家一一道來. 
 
第一層:
    首先在用戶瀏覽器端, 使用Apache的mod_deflate壓縮傳輸, 再比如: expires功能、deflate和expires功能利用的好, 就會大大提升用戶體驗效果及減少網站帶寬, 減少後端服務器的壓力. 當然, 方法還有很多, 這裏不一一細談了. 
 
提示: 有關壓縮傳輸及expires功能nginx/lighttpd等軟件同樣也有. 
 
第二層:
    頁面元素, 如圖片/js/css等或靜態數據html, 這個層面是網頁緩存層,比如CDN(效果比公司自己部署squid/nginx要好, 他們更專業, 價格低廉, 比如快網/CC等(價格80元/M/月甚至更低)而且覆蓋的城市節點更多), 自己架設squid/nginx cache來做小型CDN是次選(超大規模的公司可能會考慮風險問題實行自建加購買服務結合), 除非是爲前端的CDN提供數據源服務, 以減輕後端我們的服務器數據及存儲壓力, 而不是直接提供cache服務給最終用戶. taobao的CDN曾經因爲一部分圖片的次寸大而導致CDN壓力大的情況, 甚至對圖片尺寸大的來改小, 以達到降低流量及帶寬的作用. 
 
    提示: 我們也可以自己架設一層cache層, 對我們購買的CDN提供數據源服務, 可用的軟件有varnish/nginx/squid 等cache, 以減輕第三層靜態數據層的壓力. 在這層的前端我們也可以架設DNS服務器, 來達到跨機房業務拓展及智能解析的目的. 
 
第三層:
    靜態服務器層一般爲圖片服務器, 視頻服務器, 靜態HTML服務器. 這一層是前面緩存層和後面動態服務器層的連接紐帶, 大公司發佈新聞等內容直接由發佈人員分發到各cache節點(sina,163等都是如此), 這和一般公司的業務可能不一樣. 所以, 沒法直接的參考模仿, 比如人人的SNS. 
 
    我們可以使用Q隊列方式實現異步的分發訪問, 同時把動態發佈數據(數據庫中的數據)靜態化存儲. 即放到本層訪問, 或通過其他辦法發佈到各cache節點, 而不是直接讓所有用戶去訪問數據庫, 不知道大家發現了沒有, qq.com門戶的新聞評論多的有幾十萬條, 如果所有用戶一看新聞就加載所有評論, 那數據庫不掛纔怪. 他們的評論需要審覈(美其名約, 實際是異步的方式, 而且, 評論可能都是靜態化的或類似的靜態化或內存cache的方式), 這點可能就是需要51cto.com這樣站點學習的, 你們打開51CTO的一篇博文, 就會發現下面的評論一直都顯示出來了, 也可能是分頁的. 不過, 應該都是直接讀庫的, 一旦訪問量大, 數據庫壓力大是必然. 這裏不是說51cto網站不好, 所有的網站都是從類似的程序架構開始發展的. CU也可能是如此. 
 
    提示: 我們可以在靜態數據層的前端自己架設一層cache層, 對我們購買的CDN提供數據源服務, 可用的軟件有varnish/nginx/squid 等cache. 在這層的前端我們也可以架設DNS服務器, 來達到跨機房業務拓展及智能解析的目的. 
 
第四層:
    動態服務器層: php,java等, 只有透過了前面3層後的訪問請求纔會到這個層, 纔可能會訪問數據庫及存儲設備. 經過前三層的訪問過濾能到這層訪問請求一般來說已非常少了, 一般都是新發布的內容和新發布內容第一次瀏覽如;博文(包括微博等), BBS帖子. 
 
    特別提示: 此層可以在程序上多做文章, 比如向下訪問cache層, memcache,memcachedb,tc,mysql,oracle, 在程序級別實現分佈式訪問, 分佈式讀寫分離, 而程序級別分佈式訪問的每個db cache節點, 又可以是一組業務或者一組業務拆分開來的多臺服務器的負載均衡. 這樣的架構會爲後面的數據庫和存儲層大大的減少壓力, 那麼這裏呢, 相當於指揮部的外層了. 
 
第五層:
    數據庫cache層, 比如: memcache,memcachedb,tc等等. 
 
根據不同的業務需求, 選擇適合具體業務的數據庫. 對於memcache、memcachedb ttserver及相關nosql數據庫, 可以在第四層通過程序來實現對本層實現分佈式訪問, 每個分佈式訪問的節點都可能是一組負載均衡(數十臺機器). 
 
第六層:
    數據庫層, 一般的不是超大站點都會用mysql主從結構, 如: 163,sina,kaixin都是如此, 程序層做分佈式數據庫讀寫分離, 一主(或雙主)多從的方式, 訪問大了, 可以做級連的主從及環狀的多主多從, 然後, 實現多組負載均衡, 供前端的分佈式程序調用, 如果訪問量在大, 就需要拆業務了, 比如: 我再給某企業做兼職時, 發現類似的51cto的一個站點, 把www服務,blog服務, bbs服務都放一個服務器上, 然後做主從. 這種情況, 當業務訪問量大了, 可以簡單的把www,blog,bbs服務分別各用一組服務器拆分開, 這種方式運維都會的沒啥難度. 當然訪問量在大了, 可以繼續針對某一個服務拆分如: www庫拆分, 每個庫做一組負載均衡, 還可以對庫裏的表拆分. 需要高可用可以通過drbd等工具做成高可用方式. 對於寫大的, 可以做主主或多主的MYSQL REP方式, 對於ORACLE來說, 來幾組oracle DG(1master多salve方式)就夠了, 11G的DG可以象mysql rep一樣, 支持讀寫分離了. 當然可選的方案還有, mysql cluster 和oracle 的RAC, 玩mysql cluster和oracle RAC要需要更好更多的硬件及部署後的大量維護成本, 因此, 要綜合考慮, 到這裏訪問量還很大, 那就恭喜了, 起碼是幾千萬以上甚至上億的PV了. 
 
    象百度等巨型公司除了會採用常規的mysql及oracle數據庫庫外, 會在性能要求更高的領域, 大量的使用nosql數據庫, 然後前端在加DNS, 負載均衡, 分佈式的讀寫分離, 最後依然是拆業務, 拆庫, . . . 逐步細化, 然後每個點又可以是一組或多組機器. 
 
    特別提示: 數據庫層的硬件好壞也會決定訪問量的多少, 尤其是要考慮磁盤IO的問題, 大公司往往在性價比上做文章, 比如核心業務採用硬件netapp/emc及san光纖架構, 對於資源數據存儲, 如圖片視頻, 會採用sas或固態ssd盤, 如果數據超大, 可以採取熱點分取分存的方法: 如: 最常訪問的10-20%使用ssd存儲, 中間的20-30%採用sas盤, 最後的40-50%可以採用廉價的sata. 
 
第七層:
    千萬級PV的站如果設計的合理一些, 1, 2個NFS SERVER就足夠了. 我所維護(兼職)或經歷過的上千萬PV的用NFS及普通服務器做存儲的還有大把, 多一些磁盤, 如SAS 15K*6的, 或者用dell6850, 搞幾組 NFS存儲, 中小網站足夠了. 當然可以做成drbd+heartbeat+nfs+a/a的方式. 
 
    如果能達到本文設計要求的, 中等規模網站, 後端的數據庫及存儲壓力會非常小了.  象門戶網站級別, 如sina等,  會採用硬件netapp/emc等等硬件存儲設備或是san光纖同道, 甚至在性價比上做文章, 比如核心業務採用硬件netapp/emc及san光纖架構, 對於資源數據存儲, 如圖片視頻, 會採用sas或固態ssd盤, 如果數據超到, 可以採取熱點分取分存的方法: 如: 最常訪問的10-20%使用ssd存儲, 中間的20-30%採用sas盤, 最後的40-50%可以採用廉價的sata. 
 
    象百度等巨型公司會採用hadoop等分佈式的存儲架構, 前端在加上多層CACHE及多及的負載均衡, 同樣會根據業務進行拆分, 比如爬蟲層存儲, 索引層存儲, 服務層存儲. . . 可以更細更細. . . 爲了應付壓力, 什麼手段都用上了. 
 
 
    特殊業務, 如人人, 開心網, 包括門戶網站的評論, 微博, 大多都是異步的寫入方式, 即無論讀寫, 併發訪問數據庫都是非常少量的. 
 
    以上1-7層, 如果都搭好了, 這樣漏網到第四層動態服務器層的訪問, 就不多了. 一般的中等站點, 絕對不會對數據庫造成太大的壓力. 程序層的分佈式訪問是從千萬及PV向億級PV的發展, 當然特殊的業務 還需要特殊架構, 來合理利用數據庫和存儲. 
 
老男孩個人資料介紹: 
    資深Linux運維架構專家、高級運維總監, 從事一線運維及系統架構10年+, 曾維護千萬級/億級PV的幾個行業門戶網站, 並將多年的運維經驗成功應用到教育領域教育教學工作多年. 
    老男孩從事多年的IT教育領域一線工作, 對IT教育有着非同尋常的認識, 研習過教育心理學, 並於2008年創辦了老男孩linux運維培訓機構, 培訓中心以其獨特的先進的教育教學理念及創新的科學學習方法. 累計培養了數百名linux運維行業精英人才. 
 
個人blog:http://oldboy.blog.chinaunix.net
======================================================
歡迎廣到運維兄弟一起交流linux/unix網站運維技術!
老男孩 QQ:31333741 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章