Atitit ?高性能架構(gòu)之道

1. ?應(yīng)用服務(wù)與數(shù)據(jù)隔離

2. ?負(fù)載均衡你問題

系統(tǒng)演變到這里，將會出現(xiàn)下面四個問題：

2.1.?用戶的請求由誰來轉(zhuǎn)發(fā)到到具體的應(yīng)用服務(wù)器2.2.?有什么轉(zhuǎn)發(fā)的算法2.3.?應(yīng)用服務(wù)器如何返回用戶的請求2.4.?用戶如果每次訪問到的服務(wù)器不一樣，那么如何維護(hù)session的一致性

3.?負(fù)載均衡

3.1.?http重定向。?推薦簡單，直接js搞定負(fù)載均衡

1、HTTP重定向就是應(yīng)用層的請求轉(zhuǎn)發(fā)。用戶的請求其實已經(jīng)到了HTTP重定向負(fù)載均衡服務(wù)器，服務(wù)器根據(jù)算法要求用戶重定向，用戶收到重定向請求后，再次請求真正的集群

　　　　　　優(yōu)點：簡單。

　　　　　　缺點：性能較差。

3.2.?DNS域名解析負(fù)載均衡

2、。DNS域名解析負(fù)載均衡就是在用戶請求DNS服務(wù)器，獲取域名對應(yīng)的IP地址時，DNS服務(wù)器直接給出負(fù)載均衡后的服務(wù)器IP。

　　　　　　優(yōu)點：交給DNS，不用我們?nèi)ゾS護(hù)負(fù)載均衡服務(wù)器。

　　　　　　缺點：當(dāng)一個應(yīng)用服務(wù)器掛了，不能及時通知DNS，而且DNS負(fù)載均衡的控制權(quán)在域名服務(wù)商那里，網(wǎng)站無法做更多的改善和更強大的管理。

3.3.?反向代理服務(wù)器。

3、在用戶的請求到達(dá)反向代理服務(wù)器時（已經(jīng)到達(dá)網(wǎng)站機(jī)房），由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。常用的apache，nginx都可以充當(dāng)反向代理服務(wù)器。

　　　　　　優(yōu)點：部署簡單。

　　　　　　缺點：代理服務(wù)器可能成為性能的瓶頸，特別是一次上傳大文件。

3.4.?IP層負(fù)載均衡。

4、在請求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過修改請求的目的IP地址，從而實現(xiàn)請求的轉(zhuǎn)發(fā)，做到負(fù)載均衡。

　　　　　　優(yōu)點：性能更好。

　　　　　　缺點：負(fù)載均衡器的寬帶成為瓶頸。

3.5.?數(shù)據(jù)鏈路層負(fù)載均衡。

5、在請求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過修改請求的mac地址，從而做到負(fù)載均衡，與IP負(fù)載均衡不一樣的是，當(dāng)請求訪問完服務(wù)器之后，直接返回客戶。而無需再經(jīng)過負(fù)載均衡器。

?

2、第二個問題即是集群調(diào)度算法問題，常見的調(diào)度算法有10種。

1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請求。

　　　　　　優(yōu)點：實現(xiàn)簡單

　　　　　　缺點：不考慮每臺服務(wù)器的處理能力

2、wrr 加權(quán)調(diào)度算法。我們給每個服務(wù)器設(shè)置權(quán)值weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。

　　　　　　優(yōu)點：考慮了服務(wù)器處理能力的不同

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個key，再根據(jù)靜態(tài)映射表，查處對應(yīng)的value，即目標(biāo)服務(wù)器IP。過目標(biāo)機(jī)器超負(fù)荷，則返回空。

4、dh 目標(biāo)地址散列：同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來做哈希。

　　　　　　優(yōu)點：以上兩種算法的都能實現(xiàn)

4.?負(fù)載均衡2、第二個問題即是集群調(diào)度算法問題，常見的調(diào)度算法有10種。

?

1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請求。

　　　　　　優(yōu)點：實現(xiàn)簡單

　　　　　　缺點：不考慮每臺服務(wù)器的處理能力

2、wrr 加權(quán)調(diào)度算法。我們給每個服務(wù)器設(shè)置權(quán)值weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。

　　　　　　優(yōu)點：考慮了服務(wù)器處理能力的不同

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個key，再根據(jù)靜態(tài)映射表，查處對應(yīng)的value，即目標(biāo)服務(wù)器IP。過目標(biāo)機(jī)器超負(fù)荷，則返回空。

4、dh 目標(biāo)地址散列：同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來做哈希。

　　　　　　優(yōu)點：以上兩種算法的都能實現(xiàn)同一個用戶訪問同一個服務(wù)器。

5、lc 最少連接。優(yōu)先把請求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。

　　　　　　優(yōu)點：使得集群中各個服務(wù)器的負(fù)載更加均勻。

6、wlc 加權(quán)最少連接。在lc的基礎(chǔ)上，為每臺服務(wù)器加上權(quán)值。算法為：（活動連接數(shù)*256+非活動連接數(shù)）÷權(quán)重 ，計算出來的值小的服務(wù)器優(yōu)先被選擇。

　　　　　　優(yōu)點：可以根據(jù)服務(wù)器的能力分配請求。

7、sed 最短期望延遲。其實sed跟wlc類似，區(qū)別是不考慮非活動連接數(shù)。算法為：（活動連接數(shù)+1)*256÷權(quán)重，同樣計算出來的值小的服務(wù)器優(yōu)先被選擇。

8、nq 永不排隊。改進(jìn)的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務(wù)器的連接數(shù)為0的時候，那么假如有服務(wù)器連接數(shù)為0，均衡器直接把請求轉(zhuǎn)發(fā)給它，無需經(jīng)過sed的計算。

9、LBLC 基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近被使用的服務(wù)器，把請求轉(zhuǎn)發(fā)之，若該服務(wù)器超載，最采用最少連接數(shù)算法。

10、LBLCR 帶復(fù)制的基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近使用的“服務(wù)器組”，注意，并不是具體某個服務(wù)器，然后采用最少連接數(shù)從該組中挑出具體的某臺服務(wù)器出來，把請求轉(zhuǎn)發(fā)之。若該服務(wù)器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務(wù)器組的服務(wù)器中，找出一臺服務(wù)器出來，加入本服務(wù)器組，然后把請求轉(zhuǎn)發(fā)之。

?

3、第三個問題是集群模式問題，一般3種解決方案：

1、NAT：負(fù)載均衡器接收用戶的請求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理完請求返回給均衡器，均衡器再重新返回給用戶。

2、DR：負(fù)載均衡器接收用

5.?負(fù)載均衡問題解決?

?

5.1.?3、第三個問題是集群模式問題，一般3種解決方案：

1、NAT：負(fù)載均衡器接收用戶的請求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理完請求返回給均衡器，均衡器再重新返回給用戶。

2、DR：負(fù)載均衡器接收用戶的請求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器出來玩請求后直接返回給用戶。需要系統(tǒng)支持IP Tunneling協(xié)議，難以跨平臺。

3、TUN：同上，但無需IP Tunneling協(xié)議，跨平臺性好，大部分系統(tǒng)都可以支持。

?

5.2.?4、第四個問題是session問題，一般有4種解決方案：

1、Session Sticky。session sticky就是把同一個用戶在某一個會話中的請求，都分配到固定的某一臺服務(wù)器中，這樣我們就不需要解決跨服務(wù)器的session問題了，常見的算法有ip_hash法，即上面提到的兩種散列算法。

　　　　　　優(yōu)點：實現(xiàn)簡單。

　　　　　　缺點：應(yīng)用服務(wù)器重啟則session消失。

2、Session Replication。session replication就是在集群中復(fù)制session，使得每個服務(wù)器都保存有全部用戶的session數(shù)據(jù)。

　　　　　　優(yōu)點：減輕負(fù)載均衡服務(wù)器的壓力，不需要要實現(xiàn)ip_hasp算法來轉(zhuǎn)發(fā)請求。

　　　　　　缺點：復(fù)制時寬帶開銷大，訪問量大的話session占用內(nèi)存大且浪費。

3、Session數(shù)據(jù)集中存儲：session數(shù)據(jù)集中存儲就是利用數(shù)據(jù)庫來存儲session數(shù)據(jù)，實現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

　　　　　　優(yōu)點：相比session replication的方案，集群間對于寬帶和內(nèi)存的壓力減少了很多。

　　　　　　缺點：需要維護(hù)存儲session的數(shù)據(jù)庫。

4、Cookie Base：cookie base就是把session存在cookie中，有瀏覽器來告訴應(yīng)用服務(wù)器我的session是什么，同樣實現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

　　　　　　優(yōu)點：實現(xiàn)簡單，基本免維護(hù)。

　　　　　　缺點：cookie長度限制，安全性低，寬帶消耗。

值得一提的是：

nginx目前支持的負(fù)載均衡算法有wrr、sh

6.?使用數(shù)據(jù)庫連接池和線程池

?

7.?Cache ?redis ?前端cache等

?

7.1.?1、后臺應(yīng)用層和數(shù)據(jù)庫層的緩存

　　隨著訪問量的增加，逐漸出現(xiàn)了許多用戶訪問同一部分內(nèi)容的情況，對于這些比較熱門的內(nèi)容，沒必要每次都從數(shù)據(jù)庫讀取。我們可以使用緩存技術(shù)，例如可以使用google的開源緩存技術(shù)guava或者使用memcacahe作為應(yīng)用層的緩存，也可以使用redis作為數(shù)據(jù)庫層的緩存。

7.2.?2、頁面緩存

　　除了數(shù)據(jù)緩存，還有頁面緩存。比如使用HTML5的localstroage或者cookie。

　　優(yōu)點：

·?減輕數(shù)據(jù)庫的壓力

·?大幅度提高訪問速度

　　缺點：

·?需要維護(hù)緩存服務(wù)器

·?提高了編碼的復(fù)雜性

8.?全文索引 數(shù)據(jù)庫全文索引 與文件全文索引9.?Msa

10.?讀寫分離集群 主從復(fù)制

那么如何實現(xiàn)數(shù)據(jù)庫的讀寫分離呢？目前的思路將數(shù)據(jù)庫進(jìn)行主從拆分，所有的寫操作操作主庫，所有的讀操作操作從庫，對主庫的更新操作會通過binlog同步到從庫上，從而在從庫也可以拿到最新的數(shù)據(jù)。如此一來，讀寫不再互相阻塞，性能至少提升1倍以上。就MySQL而言，主從熱備的功能可以通過cobar、mycat之類的框架來完成。

　解決問題方案：

1.?我們可以使用MYSQL自帶的master+slave的方式實現(xiàn)主從復(fù)制。

2.?采用第三方數(shù)據(jù)庫中間件，例如mycat。mycat是從cobar發(fā)展而來的，而cobar是阿里開源的數(shù)據(jù)庫中間件，后來停止開發(fā)。mycat是國內(nèi)比較好的mysql開源數(shù)據(jù)庫分庫分表中間件。

?

11.?Cdn動靜分離12.?跟高性能數(shù)據(jù)庫 oracle取代mysql比如13.?更高性能的存儲引擎14.?Nosql 更高性能數(shù)據(jù)庫15.?存儲過程 提升單臺數(shù)據(jù)庫能力16.?單表分區(qū)17.?分布式存儲??17.1.?業(yè)務(wù)拆分垂直拆分 分庫17.2.?水平拆分 按照時間維度推薦 ，用戶地理維度等。