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