Web網(wǎng)站架構(gòu)演變趨勢(shì)

1、 Web網(wǎng)站架構(gòu)演變趨勢(shì)目錄 TOC o 1-3 h z u HYPERLINK l _Toc503790119 前言 PAGEREF _Toc503790119 h 3 HYPERLINK l _Toc503790120 階段一、單機(jī)構(gòu)建網(wǎng)站 PAGEREF _Toc503790120 h 3 HYPERLINK l _Toc503790121 階段二、應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)分離 PAGEREF _Toc503790121 h 4 HYPERLINK l _Toc503790122 階段三、應(yīng)用服務(wù)器集群 PAGEREF _Toc503790122 h 5 HYPERLINK l _Toc503

2、790123 階段四、數(shù)據(jù)庫(kù)讀寫(xiě)分離化 PAGEREF _Toc503790123 h 11 HYPERLINK l _Toc503790124 階段五、用搜索引擎緩解讀庫(kù)的壓力 PAGEREF _Toc503790124 h 13 HYPERLINK l _Toc503790125 階段六、用緩存緩解讀庫(kù)的壓力 PAGEREF _Toc503790125 h 14 HYPERLINK l _Toc503790126 階段七、數(shù)據(jù)庫(kù)水平拆分與垂直拆分 PAGEREF _Toc503790126 h 17 HYPERLINK l _Toc503790127 階段八、應(yīng)用的拆分 PAGEREF _

3、Toc503790127 h 20 HYPERLINK l _Toc503790128 階段九、引入消息中間件 PAGEREF _Toc503790128 h 23 HYPERLINK l _Toc503790129 十、總結(jié) PAGEREF _Toc503790129 h 24前言我們以javaweb為例，來(lái)搭建一個(gè)簡(jiǎn)單的電商系統(tǒng)，看看這個(gè)系統(tǒng)可以如何一步步演變。該系統(tǒng)具備的功能：用戶(hù)模塊：用戶(hù)注冊(cè)和管理商品模塊：商品展示和管理交易模塊：創(chuàng)建交易和管理階段一、單機(jī)構(gòu)建網(wǎng)站網(wǎng)站的初期，我們經(jīng)常會(huì)在單機(jī)上跑我們所有的程序和軟件。此時(shí)我們使用一個(gè)容器，如tomcat、jetty、jboos，然后直

4、接使用JSP/servlet技術(shù)，或者使用一些開(kāi)源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；最后再選擇一個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)來(lái)存儲(chǔ)數(shù)據(jù)，如mysql、sqlserver、oracle，然后通過(guò)JDBC進(jìn)行數(shù)據(jù)庫(kù)的連接和操作。把以上的所有軟件都裝載同一臺(tái)機(jī)器上，應(yīng)用跑起來(lái)了，也算是一個(gè)小系統(tǒng)了。此時(shí)系統(tǒng)結(jié)果如下：階段二、應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)分離隨著網(wǎng)站的上線(xiàn)，訪(fǎng)問(wèn)量逐步上升，服務(wù)器的負(fù)載慢慢提高，在服務(wù)器還沒(méi)有超載的時(shí)候，我們應(yīng)該就要做好準(zhǔn)備，提升網(wǎng)站的負(fù)載能力。假如我們代碼層面已難以?xún)?yōu)化，在不提高單臺(tái)機(jī)器的性能的

5、情況下，增加機(jī)器是一個(gè)不錯(cuò)的方式，不僅可以有效地提高系統(tǒng)的負(fù)載能力，而且性?xún)r(jià)比高。增加的機(jī)器用來(lái)做什么呢？此時(shí)我們可以把數(shù)據(jù)庫(kù)，web服務(wù)器拆分開(kāi)來(lái)，這樣不僅提高了單臺(tái)機(jī)器的負(fù)載能力，也提高了容災(zāi)能力。應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)分開(kāi)后的架構(gòu)如下圖所示：階段三、應(yīng)用服務(wù)器集群隨著訪(fǎng)問(wèn)量繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無(wú)法滿(mǎn)足需求了。在假設(shè)數(shù)據(jù)庫(kù)服務(wù)器沒(méi)有壓力的情況下，我們可以把應(yīng)用服務(wù)器從一臺(tái)變成了兩臺(tái)甚至多臺(tái)，把用戶(hù)的請(qǐng)求分散到不同的服務(wù)器中，從而提高負(fù)載能力。多臺(tái)應(yīng)用服務(wù)器之間沒(méi)有直接的交互，他們都是依賴(lài)數(shù)據(jù)庫(kù)各自對(duì)外提供服務(wù)。著名的做故障切換的軟件有keepalived，keepalived是一個(gè)類(lèi)似

6、于layer3、4、7交換機(jī)制的軟件，他不是某個(gè)具體軟件故障切換的專(zhuān)屬品，而是可以適用于各種軟件的一款產(chǎn)品。keepalived配合上ipvsadm又可以做負(fù)載均衡，可謂是神器。我們以增加了一臺(tái)應(yīng)用服務(wù)器為例，增加后的系統(tǒng)結(jié)構(gòu)圖如下：系統(tǒng)演變到這里，將會(huì)出現(xiàn)下面四個(gè)問(wèn)題：用戶(hù)的請(qǐng)求由誰(shuí)來(lái)轉(zhuǎn)發(fā)到到具體的應(yīng)用服務(wù)器有什么轉(zhuǎn)發(fā)的算法應(yīng)用服務(wù)器如何返回用戶(hù)的請(qǐng)求用戶(hù)如果每次訪(fǎng)問(wèn)到的服務(wù)器不一樣，那么如何維護(hù)session的一致性我們來(lái)看看解決問(wèn)題的方案：1、第一個(gè)問(wèn)題即是負(fù)載均衡的問(wèn)題，一般有5種解決方案：1、http重定向。HTTP重定向就是應(yīng)用層的請(qǐng)求轉(zhuǎn)發(fā)。用戶(hù)的請(qǐng)求其實(shí)已經(jīng)到了HTTP重定向負(fù)載

7、均衡服務(wù)器，服務(wù)器根據(jù)算法要求用戶(hù)重定向，用戶(hù)收到重定向請(qǐng)求后，再次請(qǐng)求真正的集群優(yōu)點(diǎn)：簡(jiǎn)單。缺點(diǎn)：性能較差。2、DNS域名解析負(fù)載均衡。DNS域名解析負(fù)載均衡就是在用戶(hù)請(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、反向代理服務(wù)器。在用戶(hù)的請(qǐng)求到達(dá)反向代理服務(wù)器時(shí)（已經(jīng)到達(dá)網(wǎng)站機(jī)房），由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。常用的apache，nginx都可以充當(dāng)反向代理

8、服務(wù)器。優(yōu)點(diǎn)：部署簡(jiǎn)單。缺點(diǎn)：代理服務(wù)器可能成為性能的瓶頸，特別是一次上傳大文件。4、IP層負(fù)載均衡。在請(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ù)載均衡器的寬帶成為瓶頸。5、數(shù)據(jù)鏈路層負(fù)載均衡。在請(qǐng)求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過(guò)修改請(qǐng)求的mac地址，從而做到負(fù)載均衡，與IP負(fù)載均衡不一樣的是，當(dāng)請(qǐng)求訪(fǎng)問(wèn)完服務(wù)器之后，直接返回客戶(hù)。而無(wú)需再經(jīng)過(guò)負(fù)載均衡器。2、第二個(gè)問(wèn)題即是集群調(diào)度算法問(wèn)題，常見(jiàn)的調(diào)度算法有10種。1、rr 輪詢(xún)調(diào)度算法。顧名思義，輪詢(xún)分發(fā)請(qǐng)求。優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單缺點(diǎn)：不考慮每臺(tái)服務(wù)器的處理能力2、wrr

9、 加權(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 原地址散列：提取用戶(hù)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è)用戶(hù)訪(fǎng)問(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)值。算法為：（活

10、動(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ù)算法。

11、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ù)載均衡器接收用戶(hù)的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理完請(qǐng)求返回給均衡器，均衡器再重新返回給用戶(hù)。2、DR：負(fù)載均衡器接收用戶(hù)的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器出來(lái)玩請(qǐng)求后直接返回給用戶(hù)。需要系統(tǒng)支持IP

12、Tunneling協(xié)議，難以跨平臺(tái)。3、TUN：同上，但無(wú)需IP Tunneling協(xié)議，跨平臺(tái)性好，大部分系統(tǒng)都可以支持。4、第四個(gè)問(wèn)題是session問(wèn)題，一般有4種解決方案：1、Session Sticky。session sticky就是把同一個(gè)用戶(hù)在某一個(gè)會(huì)話(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è)服

13、務(wù)器都保存有全部用戶(hù)的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)大，訪(fǎng)問(wèn)量大的話(huà)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是什么，同

14、樣實(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（支持一致性哈希）、fair（本人覺(jué)得可以歸結(jié)為lc）。但nginx作為均衡器的話(huà)，還可以一同作為靜態(tài)資源服務(wù)器。keepalived+ipvsadm比較強(qiáng)大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dhkeepalived支持集群模式有：NAT、DR、TUNnginx本身并沒(méi)有提供session同步的解決方案，而apache則提供了session共享的支持。好了，解決了以上的問(wèn)題之后，系統(tǒng)的結(jié)構(gòu)

15、如下：階段四、數(shù)據(jù)庫(kù)讀寫(xiě)分離化上面我們總是假設(shè)數(shù)據(jù)庫(kù)負(fù)載正常，但隨著訪(fǎng)問(wèn)量的的提高，數(shù)據(jù)庫(kù)的負(fù)載也在慢慢增大。那么可能有人馬上就想到跟應(yīng)用服務(wù)器一樣，把數(shù)據(jù)庫(kù)一份為二再負(fù)載均衡即可。但對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，并沒(méi)有那么簡(jiǎn)單。假如我們簡(jiǎn)單的把數(shù)據(jù)庫(kù)一分為二，然后對(duì)于數(shù)據(jù)庫(kù)的請(qǐng)求，分別負(fù)載到A機(jī)器和B機(jī)器，那么顯而易見(jiàn)會(huì)造成兩臺(tái)數(shù)據(jù)庫(kù)數(shù)據(jù)不統(tǒng)一的問(wèn)題。那么對(duì)于這種情況，我們可以先考慮使用讀寫(xiě)分離的方式。讀寫(xiě)分離后的數(shù)據(jù)庫(kù)系統(tǒng)結(jié)構(gòu)如下：這個(gè)結(jié)構(gòu)變化后也會(huì)帶來(lái)兩個(gè)問(wèn)題：主從數(shù)據(jù)庫(kù)之間數(shù)據(jù)同步問(wèn)題應(yīng)用對(duì)于數(shù)據(jù)源的選擇問(wèn)題解決問(wèn)題方案：我們可以使用MYSQL自帶的master+slave的方式實(shí)現(xiàn)主從復(fù)制。采用第

16、三方數(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ù)分表中間件。階段五、用搜索引擎緩解讀庫(kù)的壓力數(shù)據(jù)庫(kù)做讀庫(kù)的話(huà)，常常對(duì)模糊查找力不從心，即使做了讀寫(xiě)分離，這個(gè)問(wèn)題還未能解決。以我們所舉的交易網(wǎng)站為例，發(fā)布的商品存儲(chǔ)在數(shù)據(jù)庫(kù)中，用戶(hù)最常使用的功能就是查找商品，尤其是根據(jù)商品的標(biāo)題來(lái)查找對(duì)應(yīng)的商品。對(duì)于這種需求，一般我們都是通過(guò)like功能來(lái)實(shí)現(xiàn)的，但是這種方式的代價(jià)非常大。此時(shí)我們可以使用搜索引擎的倒排索引來(lái)完成。搜索引擎具有以下優(yōu)點(diǎn)：它能夠大大提高查詢(xún)速度。引入搜索引擎后也會(huì)

17、帶來(lái)以下的開(kāi)銷(xiāo)：帶來(lái)大量的維護(hù)工作，我們需要自己實(shí)現(xiàn)索引的構(gòu)建過(guò)程，設(shè)計(jì)全量/增加的構(gòu)建方式來(lái)應(yīng)對(duì)非實(shí)時(shí)與實(shí)時(shí)的查詢(xún)需求。需要維護(hù)搜索引擎集群 搜索引擎并不能替代數(shù)據(jù)庫(kù)，他解決了某些場(chǎng)景下的“讀”的問(wèn)題，是否引入搜索引擎，需要綜合考慮整個(gè)系統(tǒng)的需求。引入搜索引擎后的系統(tǒng)結(jié)構(gòu)如下：階段六、用緩存緩解讀庫(kù)的壓力1、后臺(tái)應(yīng)用層和數(shù)據(jù)庫(kù)層的緩存隨著訪(fǎng)問(wèn)量的增加，逐漸出現(xiàn)了許多用戶(hù)訪(fǎng)問(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ù)層的緩存

18、。另外，在某些場(chǎng)景下，關(guān)系型數(shù)據(jù)庫(kù)并不是很適合，例如我想做一個(gè)“每日輸入密碼錯(cuò)誤次數(shù)限制”的功能，思路大概是在用戶(hù)登錄時(shí)，如果登錄錯(cuò)誤，則記錄下該用戶(hù)的IP和錯(cuò)誤次數(shù)，那么這個(gè)數(shù)據(jù)要放在哪里呢？假如放在內(nèi)存中，那么顯然會(huì)占用太大的內(nèi)容；假如放在關(guān)系型數(shù)據(jù)庫(kù)中，那么既要建立數(shù)據(jù)庫(kù)表，還要簡(jiǎn)歷對(duì)應(yīng)的java bean，還要寫(xiě)SQL等等。而分析一下我們要存儲(chǔ)的數(shù)據(jù)，無(wú)非就是類(lèi)似ip:errorNumber這樣的key:value數(shù)據(jù)。對(duì)于這種數(shù)據(jù)，我們可以用NOSQL數(shù)據(jù)庫(kù)來(lái)代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)。2、頁(yè)面緩存除了數(shù)據(jù)緩存，還有頁(yè)面緩存。比如使用HTML5的localstroage或者cookie。

19、優(yōu)點(diǎn)：減輕數(shù)據(jù)庫(kù)的壓力大幅度提高訪(fǎng)問(wèn)速度缺點(diǎn)：需要維護(hù)緩存服務(wù)器提高了編碼的復(fù)雜性值得一提的是：緩存集群的調(diào)度算法不同與上面提到的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)。最好采用“一致性哈希算法”，這樣才能提高命中率。這個(gè)就不展開(kāi)講了，有興趣的可以查閱相關(guān)資料。加入緩存后的結(jié)構(gòu)：階段七、數(shù)據(jù)庫(kù)水平拆分與垂直拆分我們的網(wǎng)站演進(jìn)到現(xiàn)在，交易、商品、用戶(hù)的數(shù)據(jù)都還在同一個(gè)數(shù)據(jù)庫(kù)中。盡管采取了增加緩存，讀寫(xiě)分離的方式，但隨著數(shù)據(jù)庫(kù)的壓力繼續(xù)增加，數(shù)據(jù)庫(kù)的瓶頸越來(lái)越突出，此時(shí)，我們可以有數(shù)據(jù)垂直拆分和水平拆分兩種選擇。7.1、數(shù)據(jù)垂直拆分垂直拆分的意思是把數(shù)據(jù)庫(kù)中不同的業(yè)務(wù)數(shù)據(jù)拆分道不同的數(shù)據(jù)庫(kù)中，結(jié)合現(xiàn)在的例子，就是把交

20、易、商品、用戶(hù)的數(shù)據(jù)分開(kāi)。優(yōu)點(diǎn)：解決了原來(lái)把所有業(yè)務(wù)放在一個(gè)數(shù)據(jù)庫(kù)中的壓力問(wèn)題?？梢愿鶕?jù)業(yè)務(wù)的特點(diǎn)進(jìn)行更多的優(yōu)化缺點(diǎn)：需要維護(hù)多個(gè)數(shù)據(jù)庫(kù)問(wèn)題：需要考慮原來(lái)跨業(yè)務(wù)的事務(wù)跨數(shù)據(jù)庫(kù)的join解決問(wèn)題方案：我們應(yīng)該在應(yīng)用層盡量避免跨數(shù)據(jù)庫(kù)的事物，如果非要跨數(shù)據(jù)庫(kù)，盡量在代碼中控制。我們可以通過(guò)第三方應(yīng)用來(lái)解決，如上面提到的mycat，mycat提供了豐富的跨庫(kù)join方案，詳情可參考mycat官方文檔。垂直拆分后的結(jié)構(gòu)如下：7.2、數(shù)據(jù)水平拆分?jǐn)?shù)據(jù)水平拆分就是把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至多個(gè)數(shù)據(jù)庫(kù)中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個(gè)業(yè)務(wù)的數(shù)據(jù)量或者更新量到達(dá)了單個(gè)數(shù)據(jù)庫(kù)的瓶頸，這時(shí)就可以把這個(gè)表拆分到

21、兩個(gè)或更多個(gè)數(shù)據(jù)庫(kù)中。優(yōu)點(diǎn)：如果我們能客服以上問(wèn)題，那么我們將能夠很好地對(duì)數(shù)據(jù)量及寫(xiě)入量增長(zhǎng)的情況。問(wèn)題：訪(fǎng)問(wèn)用戶(hù)信息的應(yīng)用系統(tǒng)需要解決SQL路由的問(wèn)題，因?yàn)楝F(xiàn)在用戶(hù)信息分在了兩個(gè)數(shù)據(jù)庫(kù)中，需要在進(jìn)行數(shù)據(jù)操作時(shí)了解需要操作的數(shù)據(jù)在哪里。主鍵的處理也變得不同，例如原來(lái)自增字段，現(xiàn)在不能簡(jiǎn)單地繼續(xù)使用了。如果需要分頁(yè)，就麻煩了。解決問(wèn)題方案：我們還是可以通過(guò)可以解決第三方中間件，如mycat。mycat可以通過(guò)SQL解析模塊對(duì)我們的SQL進(jìn)行解析，再根據(jù)我們的配置，把請(qǐng)求轉(zhuǎn)發(fā)到具體的某個(gè)數(shù)據(jù)庫(kù)。我們可以通過(guò)UUID保證唯一或自定義ID方案來(lái)解決。mycat也提供了豐富的分頁(yè)查詢(xún)方案，比如先從每個(gè)數(shù)據(jù)庫(kù)做分頁(yè)查詢(xún)，再合并數(shù)據(jù)做一次分頁(yè)查詢(xún)等等。數(shù)據(jù)水平拆分后的結(jié)構(gòu)：階段八、應(yīng)用的拆分8.1、拆分應(yīng)用隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來(lái)越多，應(yīng)用越來(lái)越大。我們需要考慮如何避免讓?xiě)?yīng)用