Atitit ?高性能架構之道

1. 應用服務與數據隔離 2

2. 負載均衡你問題 2

2.1. 用戶的請求由誰來轉發(fā)到到具體的應用服務器 2

2.2. 有什么轉發(fā)的算法 2

2.3. 應用服務器如何返回用戶的請求 2

2.4. 用戶如果每次訪問到的服務器不一樣，那么如何維護session的一致性 2

3. 負載均衡 2

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

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

3.3. 反向代理服務器。 3

3.4. IP層負載均衡。 4

3.5. 數據鏈路層負載均衡。 4

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

5. 負載均衡問題解決 7

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

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

6. 使用數據庫連接池和線程池 9

7. Cache ?redis ?前端cache等 9

7.1. 1、后臺應用層和數據庫層的緩存 9

7.2. 2、頁面緩存 9

8. 全文索引 數據庫全文索引 與文件全文索引 10

9. Msa 10

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

11. Cdn動靜分離 11

12. 跟高性能數據庫 oracle取代mysql比如 11

13. 更高性能的存儲引擎 11

14. Nosql 更高性能數據庫 11

15. 存儲過程 提升單臺數據庫能力 11

16. 單表分區(qū) 11

17. 分布式存儲 11

17.1. 業(yè)務拆分垂直拆分 分庫 11

17.2. 水平拆分 按照時間維度推薦 ，用戶地理維度等。 11

18. 參考資料 12

18.1. 淺談web網站架構演變過程 - 語不驚人死不休 - CSDN博客.mhtml 12

?

?

1.?應用服務與數據隔離2.?負載均衡你問題

?

系統演變到這里，將會出現下面四個問題：

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

?

3.?負載均衡

?

?

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

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

　　　　　　優(yōu)點：簡單。

　　　　　　缺點：性能較差。

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

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

　　　　　　優(yōu)點：交給DNS，不用我們去維護負載均衡服務器。

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

3.3.?反向代理服務器。

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

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

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

3.4.?IP層負載均衡。

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

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

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

3.5.?數據鏈路層負載均衡。

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

?

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

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

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

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

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

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

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

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

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

?

?

?

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

?

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

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

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

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

?

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

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

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

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

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

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

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

3、Session數據集中存儲：session數據集中存儲就是利用數據庫來存儲session數據，實現了session和應用服務器的解耦。

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

　　　　　　缺點：需要維護存儲session的數據庫。

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

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

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

值得一提的是：

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

?

?

6.?使用數據庫連接池和線程池

?

7.?Cache ?redis ?前端cache等

?

7.1.?1、后臺應用層和數據庫層的緩存

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

7.2.?2、頁面緩存

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

?

　　優(yōu)點：

·?減輕數據庫的壓力

·?大幅度提高訪問速度

?

　　缺點：

·?需要維護緩存服務器

·?提高了編碼的復雜性

?

8.?全文索引 數據庫全文索引 與文件全文索引9.?Msa

?

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

?

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

?

　解決問題方案：

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

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

?

?

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

?

18.?參考資料18.1.?淺談web網站架構演變過程 - 語不驚人死不休 - CSDN博客.mhtml