|
目前網(wǎng)站架構(gòu)普通分成負(fù)載均衡層、WEB層和數(shù)據(jù)庫層，我其實(shí)正常還會多加一層，即文件服務(wù)器層，這樣我們在后面的探討進(jìn)程中，我們可以順次對這四層進(jìn)行討論；這里為了更存在壓服力，我將用三個(gè)并發(fā)較大的生產(chǎn)環(huán)境來闡明下，一個(gè)是某電子商務(wù)網(wǎng)站（并發(fā)最大值 2000，日PV500萬左右，這里說的峰值，下面的網(wǎng)站相似）、一拍網(wǎng)網(wǎng)站（并發(fā)最大值1500，日PV500萬左右）、以前保護(hù)的大型CDN廣告網(wǎng)站（并發(fā)最大值5000，日PV 5000萬左右）。 數(shù)據(jù)庫層 另外，Linux集群有一個(gè)上風(fēng)，就是它的高擴(kuò)展性，就算我們的網(wǎng)站的并發(fā)有一萬以上，我們后真?zhèn)€WEB服務(wù)是Apache，我們多加幾臺Apache服務(wù)器即可，在實(shí)際的線上維護(hù)時(shí)，我們發(fā)現(xiàn)，頂峰期間，實(shí)際上每臺WEB的并發(fā)并不算是特別大，所以網(wǎng)站的壓力在這一層我們也能通過技術(shù)手腕加以戰(zhàn)勝。 ◆級聯(lián)復(fù)制架構(gòu)，即Master-Slaves-Slaves,這個(gè)也是為了避免Slaves的讀壓力過大，而配置一層二級 Slaves，很輕易解決Master端由于從屬slave太多而成為瓶勁的危險(xiǎn)。 數(shù)據(jù)庫層的壓力，我感到網(wǎng)站的PV跟并發(fā)上去當(dāng)前，數(shù)據(jù)庫這塊的壓力是最大的，CDN大型廣告網(wǎng)站我們用的是oracle RAC方案，它保障了數(shù)據(jù)的高可用性，當(dāng)然了價(jià)錢也是十分昂貴的（假如應(yīng)用高配置的PC服務(wù)器，Oracle個(gè)別依照CPU個(gè)數(shù)收費(fèi)）；那么免費(fèi)的MySQL數(shù)據(jù)庫，面對這種并發(fā)壓力大的情形，又用哪些方式呢？首先，咱們說下傳統(tǒng)的MySQL主從方案，配置簡略，單機(jī)MySQL優(yōu)化做好事機(jī)能也不弱，如果這種架構(gòu)解決不了數(shù)據(jù)庫的壓力情況，我們能夠斟酌以下多少種方案： 文件服務(wù)器層 -->WEB層 ◆慣例復(fù)制架構(gòu)–Master-slaves，是由一個(gè)Master復(fù)制到一個(gè)或多個(gè)Salve的架構(gòu)模式，重要用于讀壓力大的利用數(shù)據(jù)庫端便宜擴(kuò)大解決計(jì)劃，讀寫分別，Master主要負(fù)責(zé)寫方面的壓力。 這須要web名目初期就計(jì)劃好這些東東，后期才轉(zhuǎn)用域名策略的本錢比較高甚至不可以實(shí)現(xiàn)，大家可以留神下，其實(shí)這一層如果網(wǎng)站是專業(yè)的圖片服務(wù)器網(wǎng)站時(shí)壓力仍是很大的，我們需要在這個(gè)上面投入足夠多的硬件資源。 WEB層這塊壓力比較大的網(wǎng)站現(xiàn)在都換成了Nginx作為WEB應(yīng)用服務(wù)器，事實(shí)上，它的抗并發(fā)能力確實(shí)超過了預(yù)期；我友人維護(hù)的一家門戶網(wǎng)站，高峰期時(shí)某臺Nginx應(yīng)用服務(wù)器的并發(fā)到達(dá)了一萬以上，但Nginx也很負(fù)責(zé)和穩(wěn)定的供給服務(wù)，在實(shí)際的生產(chǎn)環(huán)境中，如果我們考慮到后端的數(shù)據(jù)庫服務(wù)時(shí)，一萬并發(fā)應(yīng)當(dāng)也算是一個(gè)比較大的數(shù)值了。 負(fù)載均衡層 首先說下負(fù)載均衡層，我們熟悉的硬件/軟件技巧有F5/LVS、HAProxy，還有Nginx，它們的性能都是無比優(yōu)異的，且不說F5的抗并發(fā)能力，LVS現(xiàn)在在全世界范疇內(nèi)的運(yùn)用，而且淘寶當(dāng)初進(jìn)級架構(gòu)，也將LVS代替了F5，HAProxy可能大家不是特別熟習(xí)，但它確切在生產(chǎn)環(huán)境下表示優(yōu)良，強(qiáng)盛的吞吐才能，穩(wěn)定性比之硬件過尤不迭。 ◆Dual Master與級聯(lián)復(fù)制聯(lián)合架構(gòu)，即Master-Master-Slaves，最大的利益是既可以防止主Master的寫操作受到Slave集群的復(fù)制帶來的影響，而且保證了主Master的單點(diǎn)故障。 ◆MySQL的數(shù)據(jù)庫切分，我們可以通過數(shù)據(jù)切剛好技術(shù)將一個(gè)大的MySQL Server切分成多個(gè)小的MySQL Server，既解了寫入性能瓶頸問題，同時(shí)也一次晉升了全部數(shù)據(jù)庫集群的擴(kuò)展性，從而解決了數(shù)據(jù)庫壓力過大的問題，這個(gè)現(xiàn)在也是我在生產(chǎn)環(huán)境中比擬推舉的做法之一。 再說下Nginx，我是將Nginx+Keepalived架構(gòu)用于了各種出產(chǎn)環(huán)境中的，經(jīng)由長時(shí)光的線上察看，發(fā)明Nginx作為負(fù)載平衡器/反向署理也很穩(wěn)固，就算并發(fā)壓力過大，我們前面可以用F5/LVS來頂，而將Nginx作為中層代辦，這樣的后果實(shí)在也 不差，所以負(fù)載均衡層的壓力不能算是特殊大。 文件服務(wù)器層，因?yàn)榫W(wǎng)站的后期宣揚(yáng)策話，名氣也越來越大，PV值也越來越高，本來的DRBD+Heartbeat+NFS（這個(gè)其實(shí)也只是單NFS，只不外我們應(yīng)用DRBD來保證NFS的高可用罷了）已經(jīng)越來越頂不住壓力了，這個(gè)時(shí)候我們想到了分布式文件系統(tǒng)，我測試的的是MooseFS，在內(nèi)網(wǎng)測試了很長時(shí)間還是沒敢用到生產(chǎn)環(huán)境下面，googel的散布式文件體系還是很成熟的，推薦大家學(xué)習(xí)；最后還是用采取以前的CDN傳統(tǒng)的辦法解決這個(gè)問題，即用了squid反向代理加速器來解決小文件過多的問題，Nginx壯大的正則處置散發(fā)能力，也讓后端的NFS壓力變得很??；另外，我還用采用域名的疏散策略例如使用pics.xxx.com/pdf.xxx.com…來分辨標(biāo)記為a或b的一系列文件，這些文件存儲的時(shí)候，仍然按照標(biāo)志，存到pics或pdf的服務(wù)器上。這個(gè)策略將辨別機(jī)器的義務(wù)交由dns服務(wù)器來履行，擴(kuò)容時(shí)會相應(yīng)輕松。 相關(guān)的主題文章：
|