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

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

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

2.1. 用戶的請求由誰來轉(zhuǎn)發(fā)到到具體的應(yīng)用服務(wù)器 2

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

2.3. 應(yīng)用服務(wù)器如何返回用戶的請求 2

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

3. 負(fù)載均衡 2

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

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

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

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

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

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

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

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

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

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

7. Cache ?redis ?前端cache等 9

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

7.2. 2、頁面緩存 9

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

9. Msa 10

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

11. Cdn動靜分離 11

12. 跟高性能數(shù)據(jù)庫 oracle取代mysql比如 11

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

14. Nosql 更高性能數(shù)據(jù)庫 11

15. 存儲過程 提升單臺數(shù)據(jù)庫能力 11

16. 單表分區(qū) 11

17. 分布式存儲 11

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

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

18. 參考資料 12

18.1. 淺談web網(wǎng)站架構(gòu)演變過程 - 語不驚人死不休 - CSDN博客.mhtml 12

?

?

1.?應(yīng)用服務(wù)與數(shù)據(jù)隔離2.?負(fù)載均衡你問題

?

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

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ā)。用戶的請求其實(shí)已經(jīng)到了HTTP重定向負(fù)載均衡服務(wù)器，服務(wù)器根據(jù)算法要求用戶重定向，用戶收到重定向請求后，再次請求真正的集群

　　　　　　優(yōu)點(diǎn)：簡單。

　　　　　　缺點(diǎn)：性能較差。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

　　　　　　優(yōu)點(diǎn)：實(shí)現(xiàn)簡單

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

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

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

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個(gè)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)點(diǎn)：以上兩種算法的都能實(shí)現(xiàn)

?

?

?

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

?

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

　　　　　　優(yōu)點(diǎn)：實(shí)現(xiàn)簡單

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

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

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

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個(gè)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)點(diǎn)：以上兩種算法的都能實(shí)現(xiàn)同一個(gè)用戶訪問同一個(gè)服務(wù)器。

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

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

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

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

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

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

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

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

?

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

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

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

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

?

5.1.?3、第三個(gè)問題是集群模式問題，一般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、第四個(gè)問題是session問題，一般有4種解決方案：

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

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

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

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

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

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

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

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

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

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

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

　　　　　　缺點(diǎn)：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)點(diǎn)：

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

·?大幅度提高訪問速度

?

　　缺點(diǎn)：

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

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

?

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

?

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

?

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

?

　解決問題方案：

1.?我們可以使用MYSQL自帶的master+slave的方式實(shí)現(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.?水平拆分 按照時(shí)間維度推薦 ，用戶地理維度等。

?

18.?參考資料18.1.?淺談web網(wǎng)站架構(gòu)演變過程 - 語不驚人死不休 - CSDN博客.mhtml