Atitit ?高性能架構之道

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

2. ?負載均衡你問題

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

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

3.?負載均衡

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

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

　　　　　　優(yōu)點：簡單。

　　　　　　缺點：性能較差。

3.2.?DNS域名解析負載均衡

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

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

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

3.3.?反向代理服務器。

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

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

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

3.4.?IP層負載均衡。

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

2、DR：負載均衡器接收用

5.?負載均衡問題解決?

?

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

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

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

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

?

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

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

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

　　　　　　缺點：應用服務器重啟則session消失。

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

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

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

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

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

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

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

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

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

值得一提的是：

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

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

?

7.?Cache ?redis ?前端cache等

?

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

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

7.2.?2、頁面緩存

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

　　優(yōu)點：

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

·?大幅度提高訪問速度

　　缺點：

·?需要維護緩存服務器

·?提高了編碼的復雜性

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

10.?讀寫分離集群 主從復制

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

　解決問題方案：

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

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è)務拆分垂直拆分 分庫17.2.?水平拆分 按照時間維度推薦 ，用戶地理維度等。