教育行業(yè)A股IPO第一股(股票代碼 003032)

全國(guó)咨詢/投訴熱線:400-618-4000

云計(jì)算大數(shù)據(jù):構(gòu)建高性能Web站點(diǎn)

更新時(shí)間:2017年12月19日15時(shí)18分 來(lái)源:傳智播客 瀏覽次數(shù):

交流目標(biāo):

1、 熟悉網(wǎng)站演進(jìn)過(guò)程中的各個(gè)階段及技術(shù)方案(重要)

2、 熟悉大型網(wǎng)站中緩存的應(yīng)用

3、 熟悉常見(jiàn)負(fù)載均衡的手段

4、 熟悉內(nèi)存數(shù)據(jù)庫(kù)Redis

http://item.jd.com/1027067140.html

http://item.jd.com/11449803.html

大型網(wǎng)站及其架構(gòu)的演進(jìn)過(guò)程

1、什么是大型網(wǎng)站

訪問(wèn)量大、數(shù)據(jù)量大、業(yè)務(wù)復(fù)雜度高、分布式

網(wǎng)站是用來(lái)訪問(wèn)的,訪問(wèn)量大就應(yīng)該是大型網(wǎng)站?!

大量的數(shù)據(jù),或者說(shuō)海量數(shù)據(jù)。從數(shù)據(jù)中分析業(yè)務(wù)和系統(tǒng)的復(fù)雜性。

總結(jié):

那么要支持海量的數(shù)據(jù)和非常高的并發(fā)量,那么他可能是一個(gè)分布式系統(tǒng)。

2、網(wǎng)站的架構(gòu)演進(jìn)

2.1、構(gòu)建網(wǎng)站技術(shù)手段

發(fā)布一個(gè)網(wǎng)站需要哪些要素?

一個(gè)物理機(jī)、一個(gè)WEB容器、一個(gè)數(shù)據(jù)庫(kù)

開(kāi)發(fā)網(wǎng)站的技術(shù)手段?

SpringMVC/Spring/Ibatis/JDBC/Mysql

2.2、業(yè)務(wù)系統(tǒng)-電商網(wǎng)站

l 各個(gè)功能模塊通過(guò)JVM內(nèi)部方法調(diào)用來(lái)進(jìn)行交付

l 訪問(wèn)數(shù)據(jù)庫(kù)通過(guò)JDBC的方式鏈接

2.3、單機(jī)負(fù)載告警、數(shù)據(jù)庫(kù)與應(yīng)用分離

l 隨著業(yè)務(wù)量的發(fā)展,單臺(tái)物理機(jī)不能支撐。

l 重新購(gòu)置一臺(tái)物理機(jī),將數(shù)據(jù)庫(kù)服務(wù)器遷移出去。

2.4、應(yīng)用服務(wù)器負(fù)載告警、如何讓應(yīng)用服務(wù)器走向集群

l 應(yīng)用服務(wù)器壓力變大,從一臺(tái)變成兩臺(tái)。

l 他們都依賴底層數(shù)據(jù)庫(kù)對(duì)外提供服務(wù)。

l 應(yīng)用負(fù)載均衡一般使用Nginx或者apache

問(wèn)題:

1、 用戶的請(qǐng)求應(yīng)該打在哪臺(tái)應(yīng)用服務(wù)器上?(負(fù)載均衡服務(wù))

2、 Sesssion共享的問(wèn)題

解決:

1、什么是session?

在會(huì)話開(kāi)始時(shí),HTTP協(xié)議的會(huì)話機(jī)制分配一個(gè)唯一的會(huì)話標(biāo)志(SessionId),通過(guò)Cookie把這個(gè)標(biāo)志告訴瀏覽器,以后每次請(qǐng)求的時(shí)候?yàn)g覽器都會(huì)帶上這個(gè)標(biāo)志來(lái)告訴Web服務(wù)器請(qǐng)求是屬于哪個(gè)會(huì)話的。(比如保持登陸狀態(tài)、購(gòu)物車數(shù)據(jù))

2、為什么有session共享的問(wèn)題?

用戶通過(guò)負(fù)載均衡的方式,隨機(jī)訪問(wèn)到服務(wù)器A,sessionId就會(huì)創(chuàng)建到A服務(wù)器上,如果不做處理就不能保證接下來(lái)的每次請(qǐng)求都落在A服務(wù)器上。

方法一:讓同樣的seesionId每次都打在一臺(tái)服務(wù)器上。(宕機(jī)怎么辦?)

方法二:session replication 共享

方法三:使用cookies保存session中的信息

2.5、數(shù)據(jù)庫(kù)壓力變大、讀寫分離

l 寫操作主要走主庫(kù),事物中的查詢也要走主庫(kù)。

l 搜索引擎也是一個(gè)讀庫(kù)

1、搜索一個(gè)商品的名稱,like

2、根據(jù)被搜索的數(shù)據(jù)來(lái)創(chuàng)建索引(被搜索的數(shù)據(jù)變化時(shí),索引也變化)

搜索引擎提供了站內(nèi)搜索的某些場(chǎng)景讀的問(wèn)題,提供了更好的查詢效果。

2.6、彌補(bǔ)關(guān)系型數(shù)據(jù)庫(kù)的不足,引入分布式存儲(chǔ)系統(tǒng)(Redis)

分布式文件系統(tǒng)、分布式Key-Value系統(tǒng)和分布式數(shù)據(jù)庫(kù)

2.7、 讀寫分離后數(shù)據(jù)庫(kù)又遇到瓶頸

數(shù)據(jù)拆分有兩種方式,一個(gè)是垂直拆分,一個(gè)是水平拆分。垂直拆分就是把一個(gè)數(shù)據(jù)庫(kù)中不同業(yè)務(wù)單的數(shù)據(jù)分到不同的數(shù)據(jù)庫(kù)里面,水平拆分是根據(jù)一定的規(guī)則把同一業(yè)務(wù)單元的數(shù)據(jù)拆分到多個(gè)數(shù)據(jù)庫(kù)中。

2.7.1、專庫(kù)專用,垂直拆分

垂直拆分帶來(lái)的影響:

l 一些join操作會(huì)變得比較困難,因?yàn)閿?shù)據(jù)可能已經(jīng)在兩個(gè)數(shù)據(jù)庫(kù)中了。

需要應(yīng)用或者其他方案解決

2.7.2、表中的數(shù)據(jù)量比較大,水平拆分

水平拆分帶來(lái)的影響:

l 訪問(wèn)用戶信息的應(yīng)用系統(tǒng)需要解決sql路由的問(wèn)題

l 主鍵的處理也會(huì)不同,不能依靠數(shù)據(jù)庫(kù)的自增長(zhǎng)序列了

l 查詢分頁(yè)的問(wèn)題

l 包含垂直拆分的影響

2.8、分庫(kù)分表之后,應(yīng)用面對(duì)新的挑戰(zhàn)-服務(wù)化

前面所講的讀寫分離、分布式存儲(chǔ)、數(shù)據(jù)分庫(kù)分表都是在解決數(shù)據(jù)方面的問(wèn)題。

隨著應(yīng)用的的發(fā)展,應(yīng)用的功能會(huì)越來(lái)越多,應(yīng)用越來(lái)越大。我們需要考慮不讓應(yīng)用持續(xù)變大,就需要把應(yīng)用拆開(kāi)。

將應(yīng)用拆分開(kāi)來(lái)。

1、 按照業(yè)務(wù)的特性把應(yīng)用拆分,(用戶系統(tǒng)、商品系統(tǒng),訂單系統(tǒng))

2、 按照功能進(jìn)行拆分,(用戶注冊(cè)系統(tǒng)、用戶登陸系統(tǒng)、用戶信息系統(tǒng)、商品展示系統(tǒng)、商品管理系統(tǒng)……)

服務(wù)化之后,涉及到應(yīng)用與應(yīng)用之間的通信。即進(jìn)程與進(jìn)程間的通信。

遠(yuǎn)程過(guò)程調(diào)用(RPC、Netty等)

3、分布式網(wǎng)站介紹

3.1、分布式網(wǎng)站的整體結(jié)構(gòu)

在分布式網(wǎng)站中,我們會(huì)將web服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器做整體的規(guī)劃,并非采用某一臺(tái)機(jī)器做web服務(wù)器或者數(shù)據(jù)庫(kù)服務(wù)器,而是采用集群的架構(gòu)。

3.2、分布式網(wǎng)站中的服務(wù)化框架

在分布式網(wǎng)站中,會(huì)出現(xiàn)很多為了負(fù)載均衡和failover做支持而出現(xiàn)的框架,還有為項(xiàng)目解耦而出現(xiàn)的大量的RPC框架,例如做主備的keepalived、做反向代理的nginx、做負(fù)載均衡的lvs、做RPC的dubbo、netty、thrift等等。

Nginx是一個(gè)自由、開(kāi)源、高性能及輕量級(jí)的HTTP服務(wù)器及反轉(zhuǎn)代理服務(wù)器。Nginx以其高性能、穩(wěn)定、功能豐富、配置簡(jiǎn)單及占用系統(tǒng)資源少而著稱。

Nginx 超越 Apache 的高性能和穩(wěn)定性,使得國(guó)內(nèi)使用 Nginx 作為 Web 服務(wù)器的網(wǎng)站也越來(lái)越多.

Keepalived的作用是檢測(cè)web服務(wù)器的狀態(tài),如果有一臺(tái)web服務(wù)器死機(jī),或工作出現(xiàn)故障,Keepalived將檢測(cè)到,并將有故障的web服務(wù)器從系統(tǒng)中剔除,當(dāng)web服務(wù)器工作正常后Keepalived自動(dòng)將web服務(wù)器加入到服務(wù)器群中,這些工作全部自動(dòng)完成,不需要人工干涉,需要人工做的只是修復(fù)故障的web服務(wù)器。

LVS的英文全稱是Linux Virtual Server,即Linux虛擬服務(wù)器。

這些框架會(huì)在接下來(lái)的學(xué)習(xí)中一一涉獵。

RPC(Remote Procedure Call Protocol):遠(yuǎn)程過(guò)程調(diào)用協(xié)議,它是一種通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù),而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在,如TCP或UDP,為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中,RPC跨越了傳輸層和應(yīng)用層。RPC使得開(kāi)發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

RPC采用客戶機(jī)/服務(wù)器模式。請(qǐng)求程序就是一個(gè)客戶機(jī),而服務(wù)提供程序就是一個(gè)服務(wù)器。首先,客戶機(jī)調(diào)用進(jìn)程發(fā)送一個(gè)有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程,然后等待應(yīng)答信息。在服務(wù)器端,進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息的到達(dá)為止。當(dāng)一個(gè)調(diào)用信息到達(dá),服務(wù)器獲得進(jìn)程參數(shù),計(jì)算結(jié)果,發(fā)送答復(fù)信息,然后等待下一個(gè)調(diào)用信息,最后,客戶端調(diào)用進(jìn)程接收答復(fù)信息,獲得進(jìn)程結(jié)果,然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。

3.3、分布式網(wǎng)站中的消息機(jī)制

在分布式的網(wǎng)站中,消息機(jī)制不可或缺,消息機(jī)制的出現(xiàn)不僅為項(xiàng)目的解耦做了不可磨滅的共現(xiàn),也為消息的傳遞提供了另一種解決途徑。

在常用的消息機(jī)制中,ActiveMQ,RabbitMQ等簡(jiǎn)單的基于JMS規(guī)范的消息機(jī)制被廣泛應(yīng)用,而最近幾年,一種非JMS的消息機(jī)制也在互聯(lián)網(wǎng)市場(chǎng)上崛起,名為kafka。

kafka在互聯(lián)網(wǎng)中最為一種非JMS規(guī)范的消息機(jī)制,應(yīng)用越來(lái)越廣,此外,在大數(shù)據(jù)的生態(tài)圈里,kafka也有一席之地。kafka和flume、storm的結(jié)合是時(shí)下最流行的流式計(jì)算框架之一。

緩存篇

為什么要緩存?

減少數(shù)據(jù)庫(kù)訪問(wèn)(減少文件IO操作)

1.1、 動(dòng)態(tài)內(nèi)容緩存

動(dòng)態(tài)內(nèi)容緩存

將動(dòng)態(tài)內(nèi)容的HTML輸出結(jié)果緩存起來(lái)(頁(yè)面緩存),在隨后的一段時(shí)間內(nèi),當(dāng)有用戶訪問(wèn)時(shí)變跳過(guò)重復(fù)的動(dòng)態(tài)內(nèi)容計(jì)算而直接輸出。

緩存信息可以保存在文件系統(tǒng)中,也可以保存在內(nèi)存中。

需要尋找和判斷是否過(guò)期。需要更新緩存。

動(dòng)態(tài)內(nèi)容緩存技術(shù) CSI,SSI,ESI介紹 http://my.oschina.net/coldlemon/blog/341269

動(dòng)態(tài)內(nèi)容靜態(tài)化

動(dòng)態(tài)內(nèi)容緩存,雖然可以避免重復(fù)的計(jì)算,但是每次還需要調(diào)用動(dòng)態(tài)腳本的解釋器來(lái)判斷緩存是否過(guò)期以及如何讀取緩存,消耗了不少時(shí)間。

直接將內(nèi)容生成HTML文件,做成靜態(tài)頁(yè)面,返回給瀏覽器。

不是所有的內(nèi)容都能做成HTML,該技術(shù)主要使用在CMS等內(nèi)容管理系統(tǒng)上。

局部緩存

對(duì)頁(yè)面靜態(tài)資源生成HTML,動(dòng)態(tài)內(nèi)容使用異步加載(ajax)的技術(shù)。

目前該技術(shù)使用在主流的電商網(wǎng)站中。

1.2、 瀏覽器緩存

對(duì)于一些CSS樣式、圖片、腳本等靜態(tài)資源,告知瀏覽器緩存起來(lái),不要重復(fù)請(qǐng)求。

瀏覽器一般會(huì)在用戶的文件系統(tǒng)中創(chuàng)建一個(gè)目錄,用戶存放緩存文件,并給每個(gè)緩存文件上一些必要的標(biāo)記,比如過(guò)期時(shí)間等。

IE保存在磁盤,火狐在使用磁盤的同時(shí)也使用了內(nèi)存,將命中率較高的緩存內(nèi)容保存在內(nèi)存。

瀏覽器緩存原理

1、 當(dāng)瀏覽器向Web服務(wù)器請(qǐng)求一些內(nèi)容是,Web服務(wù)器需要告訴瀏覽器哪些內(nèi)容可以被緩存。

2、 瀏覽器將可以被緩存的內(nèi)容緩存起來(lái)。

3、 當(dāng)下次請(qǐng)求內(nèi)容時(shí),瀏覽器不會(huì)直接請(qǐng)求內(nèi)容,而是詢問(wèn)Web服務(wù)器是否需要更新本地緩存。

4、 Web服務(wù)器做出應(yīng)答,是否需要更新,如需要更新就將最新的內(nèi)容返回。

如何標(biāo)記哪些內(nèi)容可以被緩存?

1、在HTTP響應(yīng)都中增加last-modified關(guān)鍵詞即可。

2、瀏覽器發(fā)送請(qǐng)求是,攜帶:If-modied-sine: {時(shí)間}

3、Web服務(wù)器檢查文件最后修改的時(shí)間,特別是靜態(tài)文件,只需要判斷兩個(gè)時(shí)間是否一致。如果沒(méi)有修改 攜帶:HTTP/1.1 304 Not Modified

304意味著沒(méi)有修改。

另一種方法:(ETag)

1、 由服務(wù)器端為文件生成一個(gè)標(biāo)識(shí)號(hào) ,放在HTTP響應(yīng)頭中

ETag:“744177-b-21aa21cd232ee34”

2、 瀏覽器在下次請(qǐng)求的時(shí)候,攜帶ETag

If –node-match: 744177-b-21aa21cd232ee34

3、 Web服務(wù)器重新計(jì)算文件的ETAG,然后與接受到的ETG比較。如果同,及返回304,不同就返回新的內(nèi)容。

有沒(méi)有最優(yōu)解?

直接給文件標(biāo)記Expires,是否過(guò)期。

對(duì)于靜態(tài)內(nèi)容,Web服務(wù)器默認(rèn)情況下回開(kāi)啟Expires標(biāo)記,瀏覽器不需要重復(fù)請(qǐng)求。

谷歌日歷的CSS樣式表設(shè)置的expires 為1年,js腳本設(shè)置為1個(gè)月。

Http://www.baidu.com/css/1.css?v=2

Apache服務(wù)器如何設(shè)置js css 圖片等在本地緩存

配置文件中打開(kāi)過(guò)期擴(kuò)展#LoadModule expires_module modules/mod_expires.so

在.htaccess中加入ExpiresActive On ExpiresDefault "access plus 30 days"

1.3、 Web服務(wù)器緩存

緩存URL映射

將url地址轉(zhuǎn)換成資源路徑

www.baidu.com/12306.html à /data/www/12306.html

經(jīng)rewrite重寫的地址指向?qū)?yīng)的靜態(tài)資源路徑

www.baidu.com/12306.html à /data/www/product/12306.html

經(jīng)rewrite重寫的地址指向?qū)?yīng)的動(dòng)態(tài)資源地址

www.baidu.com/12306.html à www.baidu.com/?prodcutId=12306

緩存URL 重寫到Real Server的真實(shí)地址

www.baidu.com/12306.html à www.back-end.com/?prodcutId=12306

緩存響應(yīng)內(nèi)容

緩存靜態(tài)文件

緩存變更較小的動(dòng)態(tài)資源

緩存有效期控制,和HTTP緩存一樣的邏輯。設(shè)置expire即可。

緩存存放在哪里?開(kāi)啟磁盤緩存或者內(nèi)存緩存。

緩存文件描述符

大量靜態(tài)的小文件,需要打開(kāi)。每個(gè)文件占用一個(gè)文件描述符。

可以將文件描述符緩存在內(nèi)存中,當(dāng)需要訪問(wèn)這個(gè)文件時(shí),直接對(duì)應(yīng)到文件描述符。

Apache中關(guān)于頁(yè)面緩存的設(shè)置

http://www.cnblogs.com/yyyyy5101/articles/1899350.html

1.4、 反向代理緩存

正向代理:

用戶主動(dòng)使用代理服務(wù),服務(wù)器不知道用戶在哪里。Web服務(wù)器只知道代理服務(wù)器或者網(wǎng)關(guān)發(fā)來(lái)的請(qǐng)求,并不知道幕后還存在操作者

反向代理:

反向代理服務(wù)器的特點(diǎn)與正向代理正好相反,Web服務(wù)器隱藏在代理服務(wù)器之后。

反向代理的特點(diǎn)

調(diào)度器扮演的是用戶和實(shí)際服務(wù)器中間人的角色:

1、任何對(duì)于實(shí)際服務(wù)器的HTTP請(qǐng)求都必須經(jīng)過(guò)調(diào)度器

2、調(diào)度器必須等待實(shí)際服務(wù)器的HTTP響應(yīng),并將它反饋給用戶

內(nèi)容緩存

正向代理服務(wù)器可以設(shè)置緩存,比如一個(gè)機(jī)構(gòu)內(nèi)部網(wǎng)絡(luò)通過(guò)代理上網(wǎng),一旦某個(gè)用戶訪問(wèn)的網(wǎng)頁(yè)被緩存在代理服務(wù)器,內(nèi)部往來(lái)的其他用戶就可以快速的獲得這個(gè)網(wǎng)頁(yè)。

反向代理服務(wù)器同樣可以緩存內(nèi)容,所有的緩存機(jī)制使用仍然是使用HTTP/1.1協(xié)議。和WEB服務(wù)器緩存、瀏覽器緩存一樣。在選用反向代理服務(wù)器配置即可。

詳見(jiàn)Nginx反向代理的配置一項(xiàng)。

1.5、應(yīng)用邏輯緩存

將動(dòng)態(tài)內(nèi)容中訪問(wèn)數(shù)據(jù)庫(kù)的操作,提取到內(nèi)存數(shù)據(jù)庫(kù)中,比如Redis,減少數(shù)據(jù)庫(kù)訪問(wèn)的次數(shù),即減少文件IO操作。

實(shí)際的操作中,可以將用戶基礎(chǔ)信息、商品的基礎(chǔ)信息、收貨地址、購(gòu)物車數(shù)據(jù)、歷史購(gòu)買記錄,保存在Redis中。

將大字段保存在Mongodb(分布式文檔存儲(chǔ)數(shù)據(jù)庫(kù))。

是我們能夠自定義的,詳見(jiàn)Redis數(shù)據(jù)結(jié)構(gòu)及案例分享

1.6、數(shù)據(jù)庫(kù)查詢緩存

當(dāng)你的數(shù)據(jù)庫(kù)打開(kāi)了Query Cache(簡(jiǎn)稱QC)功能后,數(shù)據(jù)庫(kù)在執(zhí)行SELECT語(yǔ)句時(shí),會(huì)將查詢結(jié)果放到QC中,當(dāng)下一次處理同樣的SELECT請(qǐng)求時(shí),數(shù)據(jù)庫(kù)就會(huì)從QC取得結(jié) 果,而不需要去數(shù)據(jù)表中查詢。

mysql的cache功能的key的生成原理是:把select語(yǔ)句按照一定的hash規(guī)則生成唯一的key,select的結(jié)果生成value,即 key=>value。

注意,所以對(duì)于cache而言,select語(yǔ)句是區(qū)分大小寫的,也區(qū)分空格的。兩個(gè)select語(yǔ)句必須完完全全一致,才能夠獲取到同一個(gè)cache。

生成cache之后,只要該select中涉及到的table有任何的數(shù)據(jù)變動(dòng)(insert,update,delete操作等),相關(guān)的所有cache都會(huì)被刪除。

因此只有數(shù)據(jù)很少變動(dòng)的table,引入mysql 的cache才較有意義

1.7、前端優(yōu)化

1、設(shè)計(jì)更加簡(jiǎn)單的網(wǎng)頁(yè),時(shí)期包含較少的圖片和腳本,犧牲美觀和交互

2、將多個(gè)圖片合并為一個(gè)文件,使用CSS背景偏移的技術(shù)呈現(xiàn)

3、合并JavaScript腳本或者CSS樣式表,減少瀏覽器下載次數(shù)

4、充分利用HTTP中的瀏覽器Cache策略,減少重復(fù)下載。

5、將網(wǎng)站資源分布在多個(gè)域名之下,增加瀏覽器的并發(fā)下載。

默認(rèn)情況下,瀏覽器對(duì)一個(gè)域名下的資源下載有并發(fā)數(shù)據(jù)限制,從2-6不等。

通過(guò)將css樣式,圖片,js代碼放在不同的域名下,可以增加并發(fā)。

負(fù)載均衡篇

2.1、Web負(fù)載均衡

不能狹義地理解為分配給所有實(shí)際服務(wù)器一樣多的工作量,因?yàn)槎嗯_(tái)服務(wù)器的承載能力各不相同,這可能體現(xiàn)在硬件配置、網(wǎng)絡(luò)帶寬的差異,也可能因?yàn)槟撑_(tái)服務(wù)器身兼多職,我們所說(shuō)的“均衡”,也就是希望所有服務(wù)器都不要過(guò)載,并且能夠最大程序地發(fā)揮作用。

接口人故事

公司有團(tuán)隊(duì),各盡其能,工作量增加,外包。

外包接口人管理,接口人休假任務(wù)無(wú)法溝通,單點(diǎn)故障。助理。

接口人工作量分配,有的外包公司任務(wù)多,任務(wù)少,能力差,能力強(qiáng)。(負(fù)載均衡)

2.1.1、HTTP重定向

Http重定向,它可以將HTTP請(qǐng)求進(jìn)行轉(zhuǎn)移,在Web開(kāi)發(fā)中我們經(jīng)常會(huì)用它來(lái)完成自動(dòng)跳轉(zhuǎn),比如用戶登陸成功后跳轉(zhuǎn)到相應(yīng)的管理頁(yè)面。

這種重定向完全由HTTP定義,并且由HTTP代理和Web服務(wù)器共同實(shí)現(xiàn)。原理如下:

1、 當(dāng)HTTP代理(瀏覽器)向Web服務(wù)器請(qǐng)求某個(gè)URL后,Web服務(wù)器可以通過(guò)HTTP的響應(yīng)頭信息中的location標(biāo)記來(lái)返回一個(gè)新的URL

2、 HTTP代理(瀏覽器)接收到響應(yīng)頭中的location標(biāo)記,會(huì)接著請(qǐng)求location中URL,便完成了自動(dòng)跳轉(zhuǎn)。

案例展示:

http://www.php.net/downloads.php

http://php.net/get/php-7.0.2.tar.bz2/from/a/mirror

除了按照地域就近分配外,還可以使用輪詢(Round Robin)的方式請(qǐng)求方式打到不同的域名上,還以使用隨機(jī)分配等策略。

隨著吞吐率的增加,隨機(jī)調(diào)度也會(huì)逐漸趨近于順序調(diào)度的均衡效果。

結(jié)論:

不同用戶對(duì)站點(diǎn)內(nèi)頁(yè)的訪問(wèn)深度是不同的,也是我們無(wú)法控制的,如此,多臺(tái)實(shí)際服務(wù)器的實(shí)際負(fù)載差異是不可預(yù)料的,而主站點(diǎn)卻對(duì)此一無(wú)所知。

所以,在大多數(shù)情況下通過(guò)重定向來(lái)實(shí)現(xiàn)整個(gè)站點(diǎn)的負(fù)載均衡并不那么讓人滿意。但對(duì)于文件下載、廣告展示等一次性的請(qǐng)求,主站點(diǎn)調(diào)度程序可以牢牢把握控制,實(shí)際服務(wù)器的URL甚至可以含蓄的隱藏起來(lái)。

在實(shí)際的的使用中,對(duì)于不同的應(yīng)用場(chǎng)景,我們?nèi)匀恍枰J(rèn)真考慮基于重定向的負(fù)載均衡是否適用,權(quán)衡轉(zhuǎn)移請(qǐng)求的開(kāi)銷和實(shí)際請(qǐng)求的開(kāi)銷,前者的開(kāi)銷越小,越有意義。

2.1.2、DNS負(fù)載均衡

我們知道DNS負(fù)責(zé)提供域名解析,當(dāng)我們?cè)L問(wèn)某個(gè)站點(diǎn)時(shí),實(shí)際上需要通過(guò)該站點(diǎn)的域名的DNS服務(wù)器來(lái)獲取域名指定的IP地址,這一過(guò)程中,DNS服務(wù)器完成了域名到IP地址的映射,這種映射也是一對(duì)多的。

這時(shí)候,DNS便充當(dāng)了負(fù)載均衡調(diào)度器,如同HTTP的請(qǐng)求一樣,起到了重定轉(zhuǎn)移策略。

多個(gè)A記錄

在DNS的各種記錄類型中,A記錄用來(lái)指定域名對(duì)應(yīng)的IP地址。

常見(jiàn)的比較成熟的DNS系統(tǒng)如linux的bind,windows的DNS服務(wù)都支持一個(gè)域名指定多個(gè)IP地址,并且可以選擇使用各種調(diào)度策略,常見(jiàn)的便是RR(Round Robin)方式。

下圖中百度使用的最近地域(根據(jù)用戶的IP地址智能解析)

在linux下使用命令: dig baidu.com

一般情況下,可以給域名綁定多個(gè)A記錄,在實(shí)際的使用中,建議如下配置:先為每個(gè)域名配置多個(gè)CNAME,然后給CNAME指定的域名配置A記錄。這樣至少能兼顧兩個(gè)問(wèn)題:

1、 老用戶如果收藏了你的www1.baidu.com的域名,還能繼續(xù)提供服務(wù)。

2、 當(dāng)你擁有很多DNS記錄時(shí),這樣做更容易維護(hù)。比如,你希望多個(gè)二級(jí)域名都指向同一個(gè)IP地址,那么你只需要添加一個(gè)別名來(lái)代替IP地址,隨后當(dāng)你需要修改IP地址,只需要修改別名的IP地址即可。

結(jié)論:

DNS負(fù)載均衡的實(shí)現(xiàn)主要依賴DNS服務(wù)器的設(shè)置,如果你的站點(diǎn)擁有自己的DNS服務(wù)器,那么以上設(shè)置對(duì)于DNS管理員來(lái)說(shuō),并不困難,但是,大多數(shù)站點(diǎn)仍然使用第三方DNS服務(wù)商,幸運(yùn)的是,現(xiàn)在有很多DNS服務(wù)商完全支持多個(gè)A記錄的輪詢?cè)O(shè)置,我們可以根據(jù)需要設(shè)置。

對(duì)比HTTP重定向

和前面HTTP重定向相比,基于DNS的方案完全節(jié)省了所謂的主站點(diǎn),或者說(shuō)DNS服務(wù)器已經(jīng)充當(dāng)了主站點(diǎn)的職責(zé)。

不過(guò),盡管基于HTTP重定向的負(fù)載均衡系統(tǒng)受到主站點(diǎn)性能的制約,但是不可否認(rèn)重定向的方案中的調(diào)度策略具有非常好的靈活性,完全可以通過(guò)Web應(yīng)用程序?qū)崿F(xiàn)任務(wù)和你能想到的調(diào)度策略。

相比之下,為DNS服務(wù)器讓開(kāi)發(fā)自定義的調(diào)度策略就不是那么容易了,但幸運(yùn)的是,類似linux bind這樣的DNS服務(wù)軟件提供了豐富的調(diào)度策略供你選擇,其中最常用的就是根據(jù)用戶IP來(lái)進(jìn)行只能解析(上文中的百度就是如此),這意味著DNS服務(wù)器可以再所有可用的A記錄中尋找用戶最近的一臺(tái)服務(wù)器。

如何利用這種策略,完全取決于業(yè)務(wù)的狀況,可以為用戶比較集中的的一些城市提供專用的服務(wù)器,接入城市核心節(jié)點(diǎn)。也可以為為各互聯(lián)網(wǎng)運(yùn)營(yíng)商網(wǎng)絡(luò)中的用戶提供專用的服務(wù)器(聯(lián)通的歸聯(lián)通,電信的歸電信),并接入運(yùn)營(yíng)商骨干網(wǎng)絡(luò)。

2.1.3、反向代理負(fù)載均衡

幾乎所有主流的Web服務(wù)器都熱衷于支持基于反向代理的負(fù)載均衡。它的核心工作就是轉(zhuǎn)發(fā)HTTP請(qǐng)求。

相比前面的HTTP重定向和DNS解析,反向代理的調(diào)度器扮演的是用戶和實(shí)際服務(wù)器中間人的角色:

1、任何對(duì)于實(shí)際服務(wù)器的HTTP請(qǐng)求都必須經(jīng)過(guò)調(diào)度器

2、調(diào)度器必須等待實(shí)際服務(wù)器的HTTP響應(yīng),并將它反饋給用戶

特性:

1、調(diào)度策略豐富。例如可以為不同的實(shí)際服務(wù)器設(shè)置不同的權(quán)重,以達(dá)到能者多勞的效果。

2、對(duì)反向代理服務(wù)器的并發(fā)處理能力要求高,因?yàn)樗ぷ髟贖TTP層面。

3、反向代理服務(wù)器進(jìn)行轉(zhuǎn)發(fā)操作本身是需要一定開(kāi)銷的,比如創(chuàng)建線程、與后端服務(wù)器建立TCP連接、接收后端服務(wù)器返回的處理結(jié)果、分析HTTP頭部信息、用戶空間和內(nèi)核空間的頻繁切換等,雖然這部分時(shí)間并不長(zhǎng),但是當(dāng)后端服務(wù)器處理請(qǐng)求的時(shí)間非常短時(shí),轉(zhuǎn)發(fā)的開(kāi)銷就顯得尤為突出。例如請(qǐng)求靜態(tài)文件,更適合使用前面介紹的基于DNS的負(fù)載均衡方式。

4、反向代理服務(wù)器可以監(jiān)控后端服務(wù)器,比如系統(tǒng)負(fù)載、響應(yīng)時(shí)間、是否可用、TCP連接數(shù)、流量等,從而根據(jù)這些數(shù)據(jù)調(diào)整負(fù)載均衡的策略。

5、反射代理服務(wù)器可以讓用戶在一次會(huì)話周期內(nèi)的所有請(qǐng)求始終轉(zhuǎn)發(fā)到一臺(tái)特定的后端服務(wù)器上(粘滯會(huì)話),這樣的好處一是保持session的本地訪問(wèn),二是防止后端服務(wù)器的動(dòng)態(tài)內(nèi)存緩存的資源浪費(fèi)

2.1.4、IP負(fù)載均衡

因?yàn)榉聪虼矸?wù)器工作在HTTP層,其本身的開(kāi)銷就已經(jīng)嚴(yán)重制約了可擴(kuò)展性,從而也限制了它的性能極限。那能否在HTTP層面以下實(shí)現(xiàn)負(fù)載均衡呢?

NAT服務(wù)器:它工作在傳輸層,它可以修改發(fā)送來(lái)的IP數(shù)據(jù)包,將數(shù)據(jù)包的目標(biāo)地址修改為實(shí)際服務(wù)器地址。

從 Linux2.4內(nèi)核開(kāi)始,其內(nèi)置的Neftilter模塊在內(nèi)核中維護(hù)著一些數(shù)據(jù)包過(guò)濾表,這些表包含了用于控制數(shù)據(jù)包過(guò)濾的規(guī)則??上驳氖?,Linux提供了iptables來(lái)對(duì)過(guò)濾表進(jìn)行插入、修改和刪除等操作。更加令人振奮的是,Linux2.6.x內(nèi)核中內(nèi)置了IPVS模塊,它的工作性質(zhì)類型于Netfilter模塊,不過(guò)它更專注于實(shí)現(xiàn)IP負(fù)載均衡。

總結(jié):

實(shí)驗(yàn)證明使用基于NAT的負(fù)載均衡系統(tǒng)。作為調(diào)度器的NAT服務(wù)器可以將吞吐率提升到一個(gè)新的高度,幾乎是反向代理服務(wù)器的兩倍以上,這大多歸功于在內(nèi)核中進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)的較低開(kāi)銷。但是一旦請(qǐng)求的內(nèi)容過(guò)大時(shí),不論是基于反向代理還是NAT,負(fù)載均衡的整體吞吐量都差距不大,這說(shuō)明對(duì)于一些開(kāi)銷較大的內(nèi)容,使用簡(jiǎn)單的反向代理來(lái)搭建負(fù)載均衡系統(tǒng)是值考慮的。

使用策略:

一個(gè)簡(jiǎn)單有效的辦法就是將基于NAT的集群和前面的DNS混合使用,比如5個(gè)100Mbps出口寬帶的集群,然后通過(guò)DNS來(lái)將用戶請(qǐng)求均衡地指向這些集群,同時(shí),你還可以利用DNS智能解析實(shí)現(xiàn)地域就近訪問(wèn)。這樣的配置對(duì)于大多數(shù)業(yè)務(wù)是足夠了,但是對(duì)于提供下載或視頻等服務(wù)的大規(guī)模站點(diǎn),NAT服務(wù)器還是不夠出色

2.1.5、直接路由

NAT是工作在網(wǎng)絡(luò)分層模型的傳輸層(第四層),而直接路由是工作在數(shù)據(jù)鏈路層(第二層),貌似更屌些。它通過(guò)修改數(shù)據(jù)包的目標(biāo)MAC地址(沒(méi)有修改目標(biāo)IP),將數(shù)據(jù)包轉(zhuǎn)發(fā)到實(shí)際服務(wù)器上,不同的是,實(shí)際服務(wù)器的響應(yīng)數(shù)據(jù)包將直接發(fā)送給客戶端,而不經(jīng)過(guò)調(diào)度器。

2.1.6、IP隧道

基于IP隧道的請(qǐng)求轉(zhuǎn)發(fā)機(jī)制:將調(diào)度器收到的IP數(shù)據(jù)包封裝在一個(gè)新的IP數(shù)據(jù)包中,轉(zhuǎn)交給實(shí)際服務(wù)器,然后實(shí)際服務(wù)器的響應(yīng)數(shù)據(jù)包可以直接到達(dá)用戶端。目前Linux大多支持,可以用LVS來(lái)實(shí)現(xiàn),稱為L(zhǎng)VS-TUN,與LVS-DR不同的是,實(shí)際服務(wù)器可以和調(diào)度器不在同一個(gè)WANt網(wǎng)段,調(diào)度器通過(guò) IP隧道技術(shù)來(lái)轉(zhuǎn)發(fā)請(qǐng)求到實(shí)際服務(wù)器,所以實(shí)際服務(wù)器也必須擁有合法的IP地址。

總體來(lái)說(shuō),LVS-DR和LVS-TUN都適合響應(yīng)和請(qǐng)求不對(duì)稱的Web服務(wù)器,如何從它們中做出選擇,取決于你的網(wǎng)絡(luò)部署需要,因?yàn)長(zhǎng)VS-TUN可以將實(shí)際服務(wù)器根據(jù)需要部署在不同的地域,并且根據(jù)就近訪問(wèn)的原則來(lái)轉(zhuǎn)移請(qǐng)求,所以有類似這種需求的,就應(yīng)該選擇LVS-TUN。

2.1.7、負(fù)載均衡總結(jié)

l HTTP重定向負(fù)載均衡,通過(guò)HTTP協(xié)議進(jìn)行轉(zhuǎn)發(fā),常用的技術(shù)點(diǎn)是一次性下載。分配策略自己定義。

l DNS負(fù)載均衡,通過(guò)DNS服務(wù)器對(duì)域名進(jìn)行解析,按照一定的分配策略進(jìn)行分配,如就近分配和輪詢分配。靈活性沒(méi)有HTTP重定向負(fù)載均衡高。

l 反向代理負(fù)載均衡,是通過(guò)一組基于Web服務(wù)器與用戶之間的服務(wù)器來(lái)進(jìn)行的,可以配置靜態(tài)和動(dòng)態(tài)兩種策略方式來(lái)實(shí)現(xiàn)負(fù)載均衡。一般會(huì)遇到黏滯會(huì)話的問(wèn)題,需要考慮是否通過(guò)實(shí)現(xiàn)黏滯會(huì)話來(lái)遷就系統(tǒng)的特殊需求,可以考慮使用cookie、分布式session、分布式緩存的技術(shù)手段,讓后端服務(wù)器的應(yīng)用盡量與本地?zé)o關(guān)。

l IP負(fù)載均衡(DNAT端口映射),通過(guò)修改數(shù)據(jù)包請(qǐng)求轉(zhuǎn)發(fā)的IP地址,避免網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)入用戶進(jìn)程,直接在Linux內(nèi)核階段就轉(zhuǎn)發(fā)到實(shí)際服務(wù)器上。收到時(shí)候服務(wù)的反饋之后,再修改返回?cái)?shù)據(jù)包的的IP地址將返回?cái)?shù)據(jù)包執(zhí)行用戶的真正請(qǐng)求。常見(jiàn)的技術(shù)手段是Linux內(nèi)核模塊NetFilter。常用的框架就是LVS,LVS不僅可以用來(lái)做IP負(fù)載均衡,還可以使用用來(lái)做直接路由和IP隧道。

l 直接路由,通過(guò)修改數(shù)據(jù)包的目標(biāo)MAC地址,將實(shí)際服務(wù)器的響應(yīng)數(shù)據(jù)包將直接發(fā)送給用戶端,而不經(jīng)過(guò)調(diào)度器。在LVS框架中叫做LVS-DR。直接路由是基于IP別名的實(shí)現(xiàn)。

l IP隧道(IP Tunneling),簡(jiǎn)單的說(shuō),它價(jià)格調(diào)度器收到的IP數(shù)據(jù)包封裝在一個(gè)新的IP數(shù)據(jù)包中,轉(zhuǎn)交給實(shí)際服務(wù)器,然后實(shí)際服務(wù)器的響應(yīng)數(shù)據(jù)包可以直接到達(dá)客戶端。

2.1.8、負(fù)載均衡策略總結(jié)

1、輪循均衡(Round Robin):每一次來(lái)自網(wǎng)絡(luò)的請(qǐng)求輪流分配給內(nèi)部中的服務(wù)器,從1至N然后重新開(kāi)始。此種均衡算法適合于服務(wù)器組中的所有服務(wù)器都有相同的軟硬件配置并且平均服務(wù)請(qǐng)求相對(duì)均衡的情況。

2、權(quán)重輪循均衡(Weighted Round Robin):根據(jù)服務(wù)器的不同處理能力,給每個(gè)服務(wù)器分配不同的權(quán)值,使其能夠接受相應(yīng)權(quán)值數(shù)的服務(wù)請(qǐng)求。例如:服務(wù)器A的權(quán)值被設(shè)計(jì)成1,B的權(quán)值是3,C的權(quán)值是6,則服務(wù)器A、B、C將分別接受到10%、30%、60%的服務(wù)請(qǐng)求。此種均衡算法能確保高性能的服務(wù)器得到更多的使用率,避免低性能的服務(wù)器負(fù)載過(guò)重。

3、隨機(jī)均衡(Random):把來(lái)自網(wǎng)絡(luò)的請(qǐng)求隨機(jī)分配給內(nèi)部中的多個(gè)服務(wù)器。

4、權(quán)重隨機(jī)均衡(Weighted Random):此種均衡算法類似于權(quán)重輪循算法,不過(guò)在處理請(qǐng)求分擔(dān)時(shí)是個(gè)隨機(jī)選擇的過(guò)程。

5、響應(yīng)速度均衡(Response Time):負(fù)載均衡設(shè)備對(duì)內(nèi)部各服務(wù)器發(fā)出一個(gè)探測(cè)請(qǐng)求(例如Ping),然后根據(jù)內(nèi)部中各服務(wù)器對(duì)探測(cè)請(qǐng)求的最快響應(yīng)時(shí)間來(lái)決定哪一臺(tái)服務(wù)器來(lái)響應(yīng)客戶端的服務(wù)請(qǐng)求。此種均衡算法能較好的反映服務(wù)器的當(dāng)前運(yùn)行狀態(tài),但這最快響應(yīng)時(shí)間僅僅指的是負(fù)載均衡設(shè)備與服務(wù)器間的最快響應(yīng)時(shí)間,而不是客戶端與服務(wù)器間的最快響應(yīng)時(shí)間。

6、最少連接數(shù)均衡(Least Connection):客戶端的每一次請(qǐng)求服務(wù)在服務(wù)器停留的時(shí)間可能會(huì)有較大的差異,隨著工作時(shí)間加長(zhǎng),如果采用簡(jiǎn)單的輪循或隨機(jī)均衡算法,每一臺(tái)服務(wù)器上的連接進(jìn)程可能會(huì)產(chǎn)生極大的不同,并沒(méi)有達(dá)到真正的負(fù)載均衡。最少連接數(shù)均衡算法對(duì)內(nèi)部中需負(fù)載的每一臺(tái)服務(wù)器都有一個(gè)數(shù)據(jù)記錄,記錄當(dāng)前該服務(wù)器正在處理的連接數(shù)量,當(dāng)有新的服務(wù)連接請(qǐng)求時(shí),將把當(dāng)前請(qǐng)求分配給連接數(shù)最少的服務(wù)器,使均衡更加符合實(shí)際情況,負(fù)載更加均衡。此種均衡算法適合長(zhǎng)時(shí)處理的請(qǐng)求服務(wù),如FTP。

7、處理能力均衡:此種均衡算法將把服務(wù)請(qǐng)求分配給內(nèi)部中處理負(fù)荷(根據(jù)服務(wù)器CPU型號(hào)、CPU數(shù)量、內(nèi)存大小及當(dāng)前連接數(shù)等換算而成)最輕的服務(wù)器,由于考慮到了內(nèi)部服務(wù)器的處理能力及當(dāng)前網(wǎng)絡(luò)運(yùn)行狀況,所以此種均衡算法相對(duì)來(lái)說(shuō)更加精確,尤其適合運(yùn)用到第七層(應(yīng)用層)負(fù)載均衡的情況下。

8、DNS響應(yīng)均衡(Flash DNS):在Internet上,無(wú)論是HTTP、FTP或是其它的服務(wù)請(qǐng)求,客戶端一般都是通過(guò)域名解析來(lái)找到服務(wù)器確切的IP地址的。在此均衡算法下,分處在不同地理位置的負(fù)載均衡設(shè)備收到同一個(gè)客戶端的域名解析請(qǐng)求,并在同一時(shí)間內(nèi)把此域名解析成各自相對(duì)應(yīng)服務(wù)器的IP地址(即與此負(fù)載均衡設(shè)備在同一位地理位置的服務(wù)器的IP地址)并返回給客戶端,則客戶端將以最先收到的域名解析IP地址來(lái)繼續(xù)請(qǐng)求服務(wù),而忽略其它的IP地址響應(yīng)。在種均衡策略適合應(yīng)用在全局負(fù)載均衡的情況下,對(duì)本地負(fù)載均衡是沒(méi)有意義的。

服務(wù)故障的檢測(cè)方式和能力:

1、Ping偵測(cè):通過(guò)ping的方式檢測(cè)服務(wù)器及網(wǎng)絡(luò)系統(tǒng)狀況,此種方式簡(jiǎn)單快速,但只能大致檢測(cè)出網(wǎng)絡(luò)及服務(wù)器上的操作系統(tǒng)是否正常,對(duì)服務(wù)器上的應(yīng)用服務(wù)檢測(cè)就無(wú)能為力了。

2、TCP Open偵測(cè):每個(gè)服務(wù)都會(huì)開(kāi)放某個(gè)通過(guò)TCP連接,檢測(cè)服務(wù)器上某個(gè)TCP端口(如Telnet的23口,HTTP的80口等)是否開(kāi)放來(lái)判斷服務(wù)是否正常。

3、HTT PURL偵測(cè):比如向HTTP服務(wù)器發(fā)出一個(gè)對(duì)main.html文件的訪問(wèn)請(qǐng)求,如果收到錯(cuò)誤信息,則認(rèn)為服務(wù)器出現(xiàn)故障。

2.2、LVS負(fù)載均衡

2.2.1、LVS是什么

1、LVS的英文全稱是Linux Virtual Server,即Linux虛擬服務(wù)器。

2、它是我們國(guó)家的章文嵩博士的一個(gè)開(kāi)源項(xiàng)目。

2.2.2、LVS能干什么

1、 LVS主要用于多服務(wù)器的負(fù)載均衡。

2、 它工作在網(wǎng)絡(luò)層,可以實(shí)現(xiàn)高性能,高可用的服務(wù)器集群技術(shù)。

3、 它可把許多低性能的服務(wù)器組合在一起形成一個(gè)超級(jí)服務(wù)器。

4、 它配置非常簡(jiǎn)單,且有多種負(fù)載均衡的方法。

5、 它穩(wěn)定可靠,即使在集群的服務(wù)器中某臺(tái)服務(wù)器無(wú)法正常工作,也不影響整體效果。

6、 可擴(kuò)展性也非常好。

2.2.3、Nginx和lvs作對(duì)比的結(jié)果

1、nginx工作在網(wǎng)絡(luò)的應(yīng)用層,主要做反向代理;lvs工作在網(wǎng)絡(luò)層,主要做負(fù)載均衡。Nginx也同樣能承受很高負(fù)載且穩(wěn)定,但負(fù)載度和穩(wěn)定度不及l(fā)vs。

2、nginx對(duì)網(wǎng)絡(luò)的依賴較小,lvs就比較依賴于網(wǎng)絡(luò)環(huán)境。

3、在使用上,一般最前端所采取的策略應(yīng)是lvs。 nginx可作為lvs節(jié)點(diǎn)機(jī)器使用。

2.2.4、負(fù)載均衡機(jī)制

前面我們說(shuō)了LVS是工作在網(wǎng)絡(luò)層。相對(duì)于其它負(fù)載均衡的解決辦法,它的效率是非常高的。LVS的通過(guò)控制IP來(lái)實(shí)現(xiàn)負(fù)載均衡。IPVS是其具體的實(shí)現(xiàn)模塊。IPVS的主要作用:安裝在Director Server上面,在Director Server虛擬一個(gè)對(duì)外訪問(wèn)的IP(VIP)。用戶訪問(wèn)VIP,到達(dá)Director Server,Director Server根據(jù)一定的規(guī)則選擇一個(gè)Real Server,處理完成后然后返回給客戶端數(shù)據(jù)。這些步驟產(chǎn)生了一些具體的問(wèn)題,比如如何選擇具體的Real Server,Real Server如果返回給客戶端數(shù)據(jù)等等。IPVS為此有三種機(jī)制:

1. VS/NAT(Virtual Server via Network Address Translation),即網(wǎng)絡(luò)地址翻轉(zhuǎn)技術(shù)實(shí)現(xiàn)虛擬服務(wù)器。

當(dāng)請(qǐng)求來(lái)到時(shí),Diretor server上處理的程序?qū)?shù)據(jù)報(bào)文中的目標(biāo)地址(即虛擬IP地址)改成具體的某臺(tái)Real Server,端口也改成Real Server的端口,然后把報(bào)文發(fā)給Real Server。Real Server處理完數(shù)據(jù)后,需要返回給Diretor Server,然后Diretor server將數(shù)據(jù)包中的源地址和源端口改成VIP的地址和端口,最后把數(shù)據(jù)發(fā)送出去。由此可以看出,用戶的請(qǐng)求和返回都要經(jīng)過(guò)Diretor Server,如果數(shù)據(jù)過(guò)多,Diretor Server肯定會(huì)不堪重負(fù)。

2. VS/TUN(Virtual Server via IP Tunneling),即IP隧道技術(shù)實(shí)現(xiàn)虛擬服務(wù)器。

IP隧道(IP tunneling)是將一個(gè)IP報(bào)文封裝在另一個(gè)IP報(bào)文的技術(shù),這可以使得目標(biāo)為一個(gè)IP地址的數(shù)據(jù)報(bào)文能被封裝和轉(zhuǎn)發(fā)到另一個(gè)IP地址。IP隧道技術(shù)亦稱為IP封裝技術(shù)(IP encapsulation)。它跟VS/NAT基本一樣,但是Real server是直接返回?cái)?shù)據(jù)給客戶端,不需要經(jīng)過(guò)Diretor server,這大大降低了Diretor server的壓力。

3. VS/DR(Virtual Server via Direct Routing),即用直接路由技術(shù)實(shí)現(xiàn)虛擬服務(wù)器。

跟前面兩種方式,它的報(bào)文轉(zhuǎn)發(fā)方法有所不同,VS/DR通過(guò)改寫請(qǐng)求報(bào)文的MAC地址,將請(qǐng)求發(fā)送到Real Server,而Real Server將響應(yīng)直接返回給客戶,免去了VS/TUN中的IP隧道開(kāi)銷。這種方式是三種負(fù)載調(diào)度機(jī)制中性能最高最好的,但是必須要求Director Server與Real Server都有一塊網(wǎng)卡連在同一物理網(wǎng)段上。

2.2.5、LVS配置

CentOS 6.3下部署LVS(NAT)+keepalived實(shí)現(xiàn)高性能高可用負(fù)載均衡

http://www.cnblogs.com/mchina/archive/2012/08/27/2644391.html

2.3、Nginx反向代理

2.3.1、Nginx簡(jiǎn)介

Nginx是一個(gè)自由、開(kāi)源、高性能及輕量級(jí)的HTTP服務(wù)器及反轉(zhuǎn)代理服務(wù)器。Nginx以其高性能、穩(wěn)定、功能豐富、配置簡(jiǎn)單及占用系統(tǒng)資源少而著稱。

Nginx 超越 Apache 的高性能和穩(wěn)定性,使得國(guó)內(nèi)使用 Nginx 作為 Web 服務(wù)器的網(wǎng)站也越來(lái)越多.

2.3.2、基礎(chǔ)功能

反向代理加速,簡(jiǎn)單的負(fù)載均衡和容錯(cuò);

2.3.3、優(yōu)勢(shì)

1、Nginx專為性能優(yōu)化而開(kāi)發(fā),性能是其最重要的考量, 實(shí)現(xiàn)上非常注重效率 。有報(bào)告表明能支持高達(dá) 50,000 個(gè)并發(fā)連接數(shù)。

2、Nginx具有很高的穩(wěn)定性。其它HTTP服務(wù)器,當(dāng)遇到訪問(wèn)的峰值,或者有人惡意發(fā)起慢速連接時(shí),也很可能會(huì)導(dǎo)致服務(wù)器物理內(nèi)存耗盡頻繁交換,失去響應(yīng),只能重啟服務(wù)器。

例如當(dāng)前apache一旦上到200個(gè)以上進(jìn)程,web響應(yīng)速度就明顯非常緩慢了。而Nginx采取了分階段資源分配技術(shù),使得它的CPU與內(nèi)存占用率非常低。

3、nginx官方表示保持10,000個(gè)沒(méi)有活動(dòng)的連接,它只占2.5M內(nèi)存,就穩(wěn)定性而言, nginx比其他代理服務(wù)器更勝一籌。

4、Nginx支持熱部署。它的啟動(dòng)特別容易, 并且?guī)缀蹩梢宰龅?*24不間斷運(yùn)行,即使運(yùn)行數(shù)個(gè)月也不需要重新啟動(dòng)。你還能夠在不間斷服務(wù)的情況下,對(duì)軟件版本進(jìn)行進(jìn)行升級(jí)。

5、Nginx采用C進(jìn)行編寫, 不論是系統(tǒng)資源開(kāi)銷還是CPU使用效率都高很多。

2.3.4、配置

Nginx安裝與使用

http://www.cnblogs.com/skynet/p/4146083.html

Nginx配置文件詳細(xì)說(shuō)明

http://www.cnblogs.com/xiaogangqq123/archive/2011/03/02/1969006.html

本文版權(quán)歸傳智播客云計(jì)算大數(shù)據(jù)學(xué)院所有,歡迎轉(zhuǎn)載,轉(zhuǎn)載請(qǐng)注明作者出處。謝謝!
作者:傳智播客云計(jì)算大數(shù)據(jù)學(xué)院
首發(fā):http://xamj520.com/javayun
0 分享到:
和我們?cè)诰€交談!