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

交流目標(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)站

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

網(wǎng)站是用來(lái)訪(fǎng)問(wèn)的，訪(fǎng)問(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 訪(fǎng)問(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ù)載告警、如何讓?xiě)?yīng)用服務(wù)器走向集群

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

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

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

問(wèn)題：

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

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

解決：

1、什么是session?

在會(huì)話(huà)開(kāi)始時(shí)，HTTP協(xié)議的會(huì)話(huà)機(jī)制分配一個(gè)唯一的會(huì)話(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ì)話(huà)的。(比如保持登陸狀態(tài)、購(gòu)物車(chē)數(shù)據(jù))

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

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

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

方法二：session replication 共享

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

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

l 寫(xiě)操作主要走主庫(kù)，事物中的查詢(xún)也要走主庫(kù)。

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

1、搜索一個(gè)商品的名稱(chēng)，like

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

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

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

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

2.7、 讀寫(xiě)分離后數(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、專(zhuān)庫(kù)專(zhuān)用，垂直拆分

垂直拆分帶來(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 訪(fǎng)問(wèn)用戶(hù)信息的應(yīng)用系統(tǒng)需要解決sql路由的問(wèn)題

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

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

l 包含垂直拆分的影響

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

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

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

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

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

2、 按照功能進(jìn)行拆分，(用戶(hù)注冊(cè)系統(tǒng)、用戶(hù)登陸系統(tǒng)、用戶(hù)信息系統(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)資源少而著稱(chē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的英文全稱(chēng)是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采用客戶(hù)機(jī)/服務(wù)器模式。請(qǐng)求程序就是一個(gè)客戶(hù)機(jī)，而服務(wù)提供程序就是一個(gè)服務(wù)器。首先，客戶(hù)機(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)用信息，最后，客戶(hù)端調(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ù)訪(fǎng)問(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)有用戶(hù)訪(fǎ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ì)在用戶(hù)的文件系統(tǒng)中創(chuàng)建一個(gè)目錄，用戶(hù)存放緩存文件，并給每個(gè)緩存文件上一些必要的標(biāo)記，比如過(guò)期時(shí)間等。

IE保存在磁盤(pán)，火狐在使用磁盤(pán)的同時(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)容，而是詢(xún)問(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 OnExpiresDefault "access plus 30 days"

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

緩存URL映射

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

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

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

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

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

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

緩存URL 重寫(xiě)到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)啟磁盤(pán)緩存或者內(nèi)存緩存。

緩存文件描述符

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

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

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

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

1.4、 反向代理緩存

正向代理：

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

反向代理：

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

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

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

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

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

內(nèi)容緩存

正向代理服務(wù)器可以設(shè)置緩存，比如一個(gè)機(jī)構(gòu)內(nèi)部網(wǎng)絡(luò)通過(guò)代理上網(wǎng)，一旦某個(gè)用戶(hù)訪(fǎng)問(wèn)的網(wǎng)頁(yè)被緩存在代理服務(wù)器，內(nèi)部往來(lái)的其他用戶(hù)就可以快速的獲得這個(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)容中訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的操作，提取到內(nèi)存數(shù)據(jù)庫(kù)中，比如Redis，減少數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)的次數(shù)，即減少文件IO操作。

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

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

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

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

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

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

注意，所以對(duì)于cache而言，select語(yǔ)句是區(qū)分大小寫(xiě)的，也區(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í)期包含較少的圖片和腳本，犧牲美觀(guān)和交互

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)，比如用戶(hù)登陸成功后跳轉(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

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

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

結(jié)論：

不同用戶(hù)對(duì)站點(diǎn)內(nèi)頁(yè)的訪(fǎng)問(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ù)載均衡并不那么讓人滿(mǎn)意。但對(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)銷(xiāo)和實(shí)際請(qǐng)求的開(kāi)銷(xiāo)，前者的開(kāi)銷(xiāo)越小，越有意義。

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的各種記錄類(lèi)型中，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ù)用戶(hù)的IP地址智能解析)

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

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

1、 老用戶(hù)如果收藏了你的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)主要依賴(lài)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記錄的輪詢(xún)?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)的是，類(lèi)似linux bind這樣的DNS服務(wù)軟件提供了豐富的調(diào)度策略供你選擇，其中最常用的就是根據(jù)用戶(hù)IP來(lái)進(jìn)行只能解析(上文中的百度就是如此)，這意味著DNS服務(wù)器可以再所有可用的A記錄中尋找用戶(hù)最近的一臺(tái)服務(wù)器。

如何利用這種策略，完全取決于業(yè)務(wù)的狀況，可以為用戶(hù)比較集中的的一些城市提供專(zhuān)用的服務(wù)器，接入城市核心節(jié)點(diǎn)。也可以為為各互聯(lián)網(wǎng)運(yùn)營(yíng)商網(wǎng)絡(luò)中的用戶(hù)提供專(zhuān)用的服務(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)度器扮演的是用戶(hù)和實(shí)際服務(wù)器中間人的角色：

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

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

特性：

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)銷(xiāo)的，比如創(chuàng)建線(xiàn)程、與后端服務(wù)器建立TCP連接、接收后端服務(wù)器返回的處理結(jié)果、分析HTTP頭部信息、用戶(hù)空間和內(nèi)核空間的頻繁切換等，雖然這部分時(shí)間并不長(zhǎng)，但是當(dāng)后端服務(wù)器處理請(qǐng)求的時(shí)間非常短時(shí)，轉(zhuǎn)發(fā)的開(kāi)銷(xiāo)就顯得尤為突出。例如請(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ù)器可以讓用戶(hù)在一次會(huì)話(huà)周期內(nèi)的所有請(qǐng)求始終轉(zhuǎn)發(fā)到一臺(tái)特定的后端服務(wù)器上(粘滯會(huì)話(huà))，這樣的好處一是保持session的本地訪(fǎng)問(wèn)，二是防止后端服務(wù)器的動(dòng)態(tài)內(nèi)存緩存的資源浪費(fèi)

2.1.4、IP負(fù)載均衡

因?yàn)榉聪虼矸?wù)器工作在HTTP層，其本身的開(kāi)銷(xiāo)就已經(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ì)類(lèi)型于Netfilter模塊，不過(guò)它更專(zhuān)注于實(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)銷(xiāo)。但是一旦請(qǐng)求的內(nèi)容過(guò)大時(shí)，不論是基于反向代理還是NAT，負(fù)載均衡的整體吞吐量都差距不大，這說(shuō)明對(duì)于一些開(kāi)銷(xiāo)較大的內(nèi)容，使用簡(jiǎn)單的反向代理來(lái)搭建負(fù)載均衡系統(tǒng)是值考慮的。

使用策略：

一個(gè)簡(jiǎn)單有效的辦法就是將基于NAT的集群和前面的DNS混合使用，比如5個(gè)100Mbps出口寬帶的集群，然后通過(guò)DNS來(lái)將用戶(hù)請(qǐng)求均衡地指向這些集群，同時(shí)，你還可以利用DNS智能解析實(shí)現(xiàn)地域就近訪(fǎng)問(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ā)送給客戶(hù)端，而不經(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á)用戶(hù)端。目前Linux大多支持，可以用LVS來(lái)實(shí)現(xiàn)，稱(chēng)為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ì)稱(chēng)的Web服務(wù)器，如何從它們中做出選擇，取決于你的網(wǎng)絡(luò)部署需要，因?yàn)長(zhǎng)VS-TUN可以將實(shí)際服務(wù)器根據(jù)需要部署在不同的地域，并且根據(jù)就近訪(fǎng)問(wèn)的原則來(lái)轉(zhuǎn)移請(qǐng)求，所以有類(lèi)似這種需求的，就應(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)行分配，如就近分配和輪詢(xún)分配。靈活性沒(méi)有HTTP重定向負(fù)載均衡高。

l 反向代理負(fù)載均衡，是通過(guò)一組基于Web服務(wù)器與用戶(hù)之間的服務(wù)器來(lái)進(jìn)行的，可以配置靜態(tài)和動(dòng)態(tài)兩種策略方式來(lái)實(shí)現(xiàn)負(fù)載均衡。一般會(huì)遇到黏滯會(huì)話(huà)的問(wèn)題，需要考慮是否通過(guò)實(shí)現(xiàn)黏滯會(huì)話(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)入用戶(hù)進(jìn)程，直接在Linux內(nèi)核階段就轉(zhuǎn)發(fā)到實(shí)際服務(wù)器上。收到時(shí)候服務(wù)的反饋之后，再修改返回?cái)?shù)據(jù)包的的IP地址將返回?cái)?shù)據(jù)包執(zhí)行用戶(hù)的真正請(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ā)送給用戶(hù)端，而不經(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á)客戶(hù)端。

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)：此種均衡算法類(lèi)似于權(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)客戶(hù)端的服務(wù)請(qǐng)求。此種均衡算法能較好的反映服務(wù)器的當(dāng)前運(yùn)行狀態(tài)，但這最快響應(yīng)時(shí)間僅僅指的是負(fù)載均衡設(shè)備與服務(wù)器間的最快響應(yīng)時(shí)間，而不是客戶(hù)端與服務(wù)器間的最快響應(yīng)時(shí)間。

6、最少連接數(shù)均衡(Least Connection)：客戶(hù)端的每一次請(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)求，客戶(hù)端一般都是通過(guò)域名解析來(lái)找到服務(wù)器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負(fù)載均衡設(shè)備收到同一個(gè)客戶(hù)端的域名解析請(qǐng)求，并在同一時(shí)間內(nèi)把此域名解析成各自相對(duì)應(yīng)服務(wù)器的IP地址(即與此負(fù)載均衡設(shè)備在同一位地理位置的服務(wù)器的IP地址)并返回給客戶(hù)端，則客戶(hù)端將以最先收到的域名解析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文件的訪(fǎng)問(wèn)請(qǐng)求，如果收到錯(cuò)誤信息，則認(rèn)為服務(wù)器出現(xiàn)故障。

2.2、LVS負(fù)載均衡

2.2.1、LVS是什么

1、LVS的英文全稱(chēng)是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ò)的依賴(lài)較小，lvs就比較依賴(lài)于網(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ì)外訪(fǎng)問(wèn)的IP(VIP)。用戶(hù)訪(fǎng)問(wèn)VIP，到達(dá)Director Server，Director Server根據(jù)一定的規(guī)則選擇一個(gè)Real Server，處理完成后然后返回給客戶(hù)端數(shù)據(jù)。這些步驟產(chǎn)生了一些具體的問(wèn)題，比如如何選擇具體的Real Server，Real Server如果返回給客戶(hù)端數(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ā)送出去。由此可以看出，用戶(hù)的請(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ù)亦稱(chēng)為IP封裝技術(shù)(IP encapsulation)。它跟VS/NAT基本一樣，但是Real server是直接返回?cái)?shù)據(jù)給客戶(hù)端，不需要經(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ò)改寫(xiě)請(qǐng)求報(bào)文的MAC地址，將請(qǐng)求發(fā)送到Real Server，而Real Server將響應(yīng)直接返回給客戶(hù)，免去了VS/TUN中的IP隧道開(kāi)銷(xiāo)。這種方式是三種負(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)資源少而著稱(chē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專(zhuān)為性能優(yōu)化而開(kāi)發(fā)，性能是其最重要的考量, 實(shí)現(xiàn)上非常注重效率 。有報(bào)告表明能支持高達(dá) 50,000 個(gè)并發(fā)連接數(shù)。

2、Nginx具有很高的穩(wěn)定性。其它HTTP服務(wù)器，當(dāng)遇到訪(fǎ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)行編寫(xiě), 不論是系統(tǒng)資源開(kāi)銷(xiāo)還是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ù)培訓(xùn)學(xué)院

首發(fā)：http://cloud.itheima.com/