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

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

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

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

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

3.?負(fù)載均衡

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

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

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

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

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

2、。DNS域名解析負(fù)載均衡就是在用戶請(qǐng)求DNS服務(wù)器，獲取域名對(duì)應(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)站無(wú)法做更多的改善和更強(qiáng)大的管理。

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

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

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

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

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

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

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

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

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

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

?

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

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

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

　　　　　　缺點(diǎn)：不考慮每臺(tái)服務(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)映射表，查處對(duì)應(yīng)的value，即目標(biāo)服務(wù)器IP。過(guò)目標(biāo)機(jī)器超負(fù)荷，則返回空。

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

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

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

?

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

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

　　　　　　缺點(diǎn)：不考慮每臺(tái)服務(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)映射表，查處對(duì)應(yīng)的value，即目標(biāo)服務(wù)器IP。過(guò)目標(biāo)機(jī)器超負(fù)荷，則返回空。

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

?

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

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

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

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

?

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

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

　　　　　　優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎ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算法來(lái)轉(zhuǎn)發(fā)請(qǐng)求。

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

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

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

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

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

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

　　　　　　缺點(diǎn)：cookie長(zhǎng)度限制，安全性低，寬帶消耗。

值得一提的是：

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

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

?

7.?Cache ?redis ?前端cache等

?

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

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

7.2.?2、頁(yè)面緩存

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

　　優(yōu)點(diǎn)：

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

·?大幅度提高訪問(wèn)速度

　　缺點(diǎn)：

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

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

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

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

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

　解決問(wèn)題方案：

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

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

?

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