建站
咨詢
售后
建站咨詢
新聞中心
在當(dāng)今的信息時代中，數(shù)據(jù)量的爆炸式增長已經(jīng)成為了一種趨勢，如何對這些海量數(shù)據(jù)進(jìn)行處理，就成為了互聯(lián)網(wǎng)企業(yè)的一個難題。對于擁有各種Web應(yīng)用程序的公司來說，數(shù)據(jù)庫是支撐其系統(tǒng)運(yùn)行的核心，但是如果數(shù)據(jù)量龐大的話，數(shù)據(jù)庫應(yīng)付也會變得繁瑣。為了解決這個問題，一種稱之為垂直分庫的技術(shù)被廣泛應(yīng)用。
成都創(chuàng)新互聯(lián)專注于中大型企業(yè)的網(wǎng)站建設(shè)、做網(wǎng)站和網(wǎng)站改版、網(wǎng)站營銷服務(wù)，追求商業(yè)策劃與數(shù)據(jù)分析、創(chuàng)意藝術(shù)與技術(shù)開發(fā)的融合，累計客戶1000多家，服務(wù)滿意度達(dá)97%。幫助廣大客戶順利對接上互聯(lián)網(wǎng)浪潮，準(zhǔn)確優(yōu)選出符合自己需要的互聯(lián)網(wǎng)運(yùn)用，我們將一直專注品牌網(wǎng)站建設(shè)和互聯(lián)網(wǎng)程序開發(fā)，在前進(jìn)的路上，與客戶一起成長！
垂直分庫技術(shù)是一種將不同的數(shù)據(jù)庫表分離到不同的數(shù)據(jù)庫中的技術(shù)，這使各個數(shù)據(jù)庫獨(dú)立管理、互相獨(dú)立。在這種技術(shù)的幫助下，我們可以將同一個數(shù)據(jù)庫中繁瑣、易混淆的數(shù)據(jù)表分離到不同的數(shù)據(jù)庫中，并通過另外的工具（例如一些訪問工具、搬運(yùn)工具等）來保持其數(shù)據(jù)的相對穩(wěn)定。使用這種技術(shù)優(yōu)化數(shù)據(jù)庫，能夠顯著提升系統(tǒng)的性能和可擴(kuò)展性。
垂直分庫的優(yōu)點(diǎn)
垂直分庫的優(yōu)點(diǎn)很多。它可以解決單一數(shù)據(jù)庫管理過于復(fù)雜的問題。隨著企業(yè)的發(fā)展，數(shù)據(jù)庫的大小也會有所增加，甚至有時大小會超出了單個數(shù)據(jù)庫的承載能力。如果我們將這些大量數(shù)據(jù)全部存儲在同一個庫中，那么對于操作這些數(shù)據(jù)的程序來說就會變得非常難減，操作的效率也會極度降低。垂直分庫的解決方案是將不同的數(shù)據(jù)表分開，用獨(dú)立的數(shù)據(jù)庫來進(jìn)行管理，這樣程序的信息只會在特定的數(shù)據(jù)庫表中進(jìn)行處理，程序的效率也會因此大幅提升。
另外，垂直分庫也可以提高程序的可擴(kuò)展性。對于每個Web程序來說，它最開始進(jìn)入市場時的數(shù)據(jù)量是有限的。然而，隨著運(yùn)營時間的增長，數(shù)據(jù)的增長速度也開始變快。如果我們使用一個傳統(tǒng)的單個數(shù)據(jù)庫進(jìn)行管理，隨著數(shù)據(jù)的增多，會使數(shù)據(jù)表變得雜亂無序。這樣不僅會降低程序的效率，還會使得擴(kuò)展和添加新功能變得更加麻煩。但如果采用垂直分庫的技術(shù)，可以把數(shù)據(jù)表拆分到多個數(shù)據(jù)庫中，這樣就可以避免表間互相干擾的情況出現(xiàn)，也方便了未來的擴(kuò)展。
垂直分庫的缺點(diǎn)
雖然垂直分庫技術(shù)可以優(yōu)化數(shù)據(jù)庫性能，但是這種技術(shù)并不是萬能的。垂直分庫的缺點(diǎn)是，使用它需要對系統(tǒng)架構(gòu)有一個全面的規(guī)劃。這種規(guī)劃首先要確定各數(shù)據(jù)表的關(guān)系，并根據(jù)功能性把它們組織在一起，然后按照一定的規(guī)則進(jìn)行垂直分庫。因此，在實(shí)施垂直分庫的過程中需要花費(fèi)一定的時間和精力，否則會帶來數(shù)據(jù)分發(fā)和管理的問題。
另一個缺點(diǎn)是，垂直分庫可能會導(dǎo)致系統(tǒng)不穩(wěn)定。由于數(shù)據(jù)表在不同的數(shù)據(jù)庫中，系統(tǒng)的并發(fā)性，特別是事務(wù)的并發(fā)性受到威脅。因此，在進(jìn)行垂直分庫的時必須要考慮到系統(tǒng)的性能和可用性，仔細(xì)測試與修改環(huán)境中的應(yīng)用程序，避免出現(xiàn)由于數(shù)據(jù)庫之間的矛盾或者配置不一致造成的問題。
結(jié)論
綜上所述，垂直分庫是一種很好的數(shù)據(jù)庫解決方案。它可以優(yōu)化系統(tǒng)性能和可擴(kuò)展性，但也存在一定的負(fù)面影響。在使用垂直分庫之前，必須要深入了解您的應(yīng)用程序的需求，考慮可以優(yōu)化的數(shù)據(jù)表以及規(guī)劃有效的數(shù)據(jù)表存儲，以確保成功地實(shí)施此解決方案。
相關(guān)問題拓展閱讀：
- 分布式緩存的主要作用？
- 如何搭建億級并發(fā)的系統(tǒng)架構(gòu)？
分布式緩存的主要作用？
分布式緩存主要用于在高并發(fā)環(huán)境下，減輕數(shù)據(jù)庫的壓力，提高系統(tǒng)的響應(yīng)速度和并發(fā)吞吐。當(dāng)大量的讀、寫請求涌向數(shù)據(jù)庫時，磁盤的處理速度與內(nèi)存顯然不在一個量級，因此，在數(shù)據(jù)庫之前加一層緩存，能夠顯著提高系統(tǒng)的響應(yīng)速度，并降低數(shù)據(jù)庫的壓力。作為傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，MySQL提供完整的ACID操作，支持豐富的數(shù)據(jù)類型、強(qiáng)大的關(guān)聯(lián)查詢、where語句等，能夠非?？鸵椎亟⒉樵兯饕?，執(zhí)行復(fù)雜的內(nèi)連接、外連接、求和、排序、分組等操作，并且支持存儲過程、函數(shù)等功能，產(chǎn)品成熟度高，功能強(qiáng)大。但是，對于需要應(yīng)對高并發(fā)訪問并且存儲海量數(shù)據(jù)的場景來說，出于對性能的考慮，不得不放棄很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫原本強(qiáng)大的功能，犧牲了系統(tǒng)的易用性，并且使得系統(tǒng)的設(shè)計和管理變得更為復(fù)雜。這也使得在過去幾年中，流行著另一種新的存儲解決方案——NoSQL，它與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫更大的差別在于，它不使用SQL作為查詢語言來查找數(shù)據(jù)，而采用key-value形式進(jìn)行查找，提供了更高的查詢效率及吞吐，并且能夠更加方便地進(jìn)行擴(kuò)展，存儲海量數(shù)據(jù)，在數(shù)千個節(jié)點(diǎn)上進(jìn)行分區(qū)，自動進(jìn)行數(shù)據(jù)的復(fù)制和備份。在分布式系統(tǒng)中，消息作為應(yīng)用間通信的一種方式，得到了十分廣泛的應(yīng)用。消息可以被保存在隊列中，直到被接收者取出，由于消息發(fā)送者不需要同步等待消息接收者的響應(yīng)，消息的異步接收降低了系統(tǒng)集成的耦合度，提升了分布式系統(tǒng)協(xié)作的效率，使得系統(tǒng)能夠更快地響應(yīng)用戶，提供更高的吞吐。
當(dāng)系統(tǒng)處于峰值壓力時，分布式消息隊列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個系統(tǒng)被壓垮。垂直化的搜索引擎在分布式系統(tǒng)中是一個非常重要的角色，它既能夠滿足用戶對于全文檢索、模糊匹配的需求，解決數(shù)據(jù)庫like查詢效率低下的問題，又能夠解決分布式環(huán)境下，由于采用分庫分表，或者使用NoSQL數(shù)據(jù)庫，導(dǎo)致無法進(jìn)行多表關(guān)聯(lián)或者進(jìn)行復(fù)雜查詢的問題。
你好，分布式緩存能夠處理大量的動態(tài)數(shù)據(jù)，因此比較適合應(yīng)用在Web 2.0時代中的社交網(wǎng)站等需要由用戶生成內(nèi)容的場景。從本地緩存擴(kuò)展到分布式緩存后，關(guān)注重點(diǎn)從CPU、內(nèi)存、緩存之間的數(shù)據(jù)傳輸速度差異也擴(kuò)展到了業(yè)務(wù)系統(tǒng)、數(shù)據(jù)庫、分布式緩存之間的數(shù)據(jù)傳輸速度差異。
如何搭建億級并發(fā)的系統(tǒng)架構(gòu)？
分布式+緩存
想設(shè)計億萬級高并發(fā)架構(gòu)，你要先知道高并發(fā)是什么？
面對流量高峰，不同的企業(yè)是如何通過技術(shù)手段解決高并發(fā)難題的呢?
0、引言
軟件系統(tǒng)有三個追求：高性能、高并發(fā)、高可用，俗稱三高。三者既有區(qū)別也有聯(lián)系，門門道道很多，全面討論需要三天三夜，本篇討論高并發(fā)。
高并發(fā)（High Concurrency）。并發(fā)是操作系統(tǒng)領(lǐng)域的一個概念，指的是一段櫻芹時間內(nèi)多任務(wù)流交替執(zhí)行的現(xiàn)象，后來這個概念被泛化，高并發(fā)用來指大流量、高請求的業(yè)務(wù)情景，比如春運(yùn)搶票，電商雙十一，秒殺大促等場景。
很多程序員每天忙著搬磚，平時接觸不到高并發(fā)，哪天受不了跑去面試，還常常會被面試官犀利的高并發(fā)問題直接KO，其實(shí)吧，高并發(fā)系統(tǒng)也不高深，我保證任何一個智商在線的看過這篇文章后，都能戰(zhàn)勝恐懼，重拾生活的信心。
本文先介紹高并發(fā)系統(tǒng)的度量指標(biāo)，然后講述高并發(fā)系統(tǒng)的設(shè)計思路，再梳理高并發(fā)的關(guān)鍵技術(shù)，最后結(jié)合作者的經(jīng)驗(yàn)做一些延伸探討。
1、高并發(fā)的度量指標(biāo)
既然是高并發(fā)系統(tǒng)，那并發(fā)一定要高，不然就名不副實(shí)。并發(fā)的指標(biāo)一般有QPS、TPS、IOPS，這幾個指標(biāo)都是可歸為系統(tǒng)吞吐率，QPS越高系統(tǒng)能hold住的請求數(shù)越多，但光關(guān)注這幾個指標(biāo)不夠，我們還需要關(guān)注RT，即響應(yīng)時間，也就是從發(fā)出request到收到response的時延，這個指標(biāo)跟吞吐往往是此消彼長的，我們追求的是一定時延下的高吞吐。
比如有100萬次請求，99萬次請求都在10毫秒內(nèi)響應(yīng)，其他次數(shù)10秒才響應(yīng)，平均時延不高，但時延高的用戶受不了，所以，就有了TP90/TP99指標(biāo)，這個指標(biāo)不是求平均，而是把時延從小到大排序，取排名90%/99%的時延，這個指標(biāo)越大，對慢請求越敏感。
除此之外，有時候，我們也會關(guān)注可用性指標(biāo)，這可歸到穩(wěn)定性。
一般而言，用戶感知友好的高并發(fā)系統(tǒng)，時延應(yīng)該控制在250毫秒以內(nèi)。
什么樣的系統(tǒng)才能稱為高并發(fā)？這個不好回答，因?yàn)樗Q于系統(tǒng)或者業(yè)務(wù)的類型。不過我可以告訴你一些眾所周知的指標(biāo)，這樣能幫助你下次在跟人扯淡的時候稍微靠點(diǎn)兒譜，不至于貽笑大方。
通常，數(shù)據(jù)庫單機(jī)每秒也就能抗住幾千這個量級，而做邏輯處理的服務(wù)單臺每秒抗幾萬、甚至幾十萬都有可能，而消息隊列等中間件單機(jī)每秒處理個幾萬沒問題，所以我們經(jīng)常聽到每秒處理數(shù)百萬、數(shù)千萬的消息中間件集群，而像阿某的API網(wǎng)關(guān)，每日百億請求也有可能。
2、高并發(fā)的設(shè)計思路
高并發(fā)的設(shè)計思路有兩個方向：
垂直方向擴(kuò)展，也叫豎向擴(kuò)展
水平方向擴(kuò)展，也叫橫向擴(kuò)展
垂直方向：提升單機(jī)能力
提升單機(jī)處理能力又可分為硬件和軟件兩個方面：
硬件方向，很好理解，花錢升級機(jī)器，更多核更高主頻更大存儲空間更多帶寬
軟件方向，包括用各快的數(shù)據(jù)結(jié)構(gòu)，改進(jìn)架構(gòu)，應(yīng)用多線程、協(xié)程，以及上性能優(yōu)化各種手段，但這玩意兒天花板低，就像提升個人產(chǎn)出一樣，996、007、最多24 X 7。
水平方向：分布式集群
為了解決分布式系統(tǒng)的復(fù)雜性問題，一般會用到架構(gòu)分層和服務(wù)拆分，通過分層做隔離，通過微服務(wù)解耦。
這個理論上沒有上限，只要做好層次和服務(wù)劃分，加機(jī)器擴(kuò)容就能滿足需求，但實(shí)際上并非如此，一方面分布式會增加系統(tǒng)復(fù)雜性，另一方面集群規(guī)模上去之后，也會引入一堆AIOps、服務(wù)發(fā)現(xiàn)、服務(wù)治理的新問題。
因?yàn)榇怪毕虻南拗?，所以，我們通常更關(guān)注水平擴(kuò)展，高并發(fā)系統(tǒng)的實(shí)施也主要圍繞水平方向展開。
3、高并發(fā)的關(guān)鍵技術(shù)
玩具式的網(wǎng)絡(luò)服務(wù)程序，用戶可以直連服務(wù)器，甚至不需要數(shù)據(jù)庫，直接寫磁盤文租扒件。但春運(yùn)購票系統(tǒng)顯然不能這么做，它肯定扛不住這個壓力，那一般的高并發(fā)系統(tǒng)是怎么做呢？比如某寶這樣的正經(jīng)系統(tǒng)是怎么處理高并發(fā)的呢？
其實(shí)大的思路都差不多，層次劃分 + 功能劃分。可以把層次劃分理解為水平方向的劃分，而功能劃分理解為垂直方向的劃分。
首先，用戶不能直連服務(wù)器，要做分布式就要解決“分”的問題，有多個服務(wù)實(shí)例就需要做負(fù)載均衡，有不同服務(wù)類型就需要服務(wù)發(fā)現(xiàn)。
集群化：負(fù)載均衡
負(fù)載均衡就是把負(fù)載（脊型畢request）均衡分配到不同的服務(wù)實(shí)例，利用集群的能力去對抗高并發(fā)，負(fù)載均衡是服務(wù)集群化的實(shí)施要素，它分3種：
DNS負(fù)載均衡，客戶端通過URL發(fā)起網(wǎng)絡(luò)服務(wù)請求的時候，會去DNS服務(wù)器做域名解釋，DNS會按一定的策略（比如就近策略）把URL轉(zhuǎn)換成IP地址，同一個URL會被解釋成不同的IP地址，這便是DNS負(fù)載均衡，它是一種粗粒度的負(fù)載均衡，它只用URL前半部分，因?yàn)镈NS負(fù)載均衡一般采用就近原則，所以通常能降低時延，但DNS有cache，所以也會更新不及時的問題。
硬件負(fù)載均衡，通過布置特殊的負(fù)載均衡設(shè)備到機(jī)房做負(fù)載均衡，比如F5，這種設(shè)備貴，性能高，可以支撐每秒百萬并發(fā)，還能做一些安全防護(hù)，比如防火墻。
軟件負(fù)載均衡，根據(jù)工作在ISO 7層網(wǎng)絡(luò)模型的層次，可分為四層負(fù)載均衡（比如章文嵩博士的LVS）和七層負(fù)載均衡（NGINX），軟件負(fù)載均衡配置靈活，擴(kuò)展性強(qiáng)，阿某云的SLB作為服務(wù)對外售賣，Nginx可以對URL的后半部做解釋承擔(dān)API網(wǎng)關(guān)的職責(zé)。
所以，完整的負(fù)載均衡鏈路是 client DNS負(fù)載均衡 -> F5 -> LVS/SLB -> NGINX
不管選擇哪種LB策略，或者組合LB策略，邏輯上，我們都可以視為負(fù)載均衡層，通過添加負(fù)載均衡層，我們將負(fù)載均勻分散到了后面的服務(wù)集群，具備基礎(chǔ)的高并發(fā)能力，但這只是萬里長征之一步。
數(shù)據(jù)庫層面：分庫分表+讀寫分離
前面通過負(fù)載均衡解決了無狀態(tài)服務(wù)的水平擴(kuò)展問題，但我們的系統(tǒng)不全是無狀態(tài)的，后面通常還有有狀態(tài)的數(shù)據(jù)庫，所以解決了前面的問題，存儲有可能成為系統(tǒng)的瓶頸，我們需要對有狀態(tài)存儲做分片路由。
數(shù)據(jù)庫的單機(jī)QPS一般不高，也就幾千，顯然滿足不了高并發(fā)的要求。
所以，我們需要做分庫分表 + 讀寫分離。
就是把一個庫分成多個庫，部署在多個數(shù)據(jù)庫服務(wù)上，主庫承載寫請求，從庫承載讀請求。從庫可以掛載多個，因?yàn)楹芏鄨鼍皩懙恼埱筮h(yuǎn)少于讀的請求，這樣就把對單個庫的壓力降下來了。
如果寫的請求上升就繼續(xù)分庫分表，如果讀的請求上升就掛更多的從庫，但數(shù)據(jù)庫天生不是很適合高并發(fā)，而且數(shù)據(jù)庫對機(jī)器配置的要求一般很高，導(dǎo)致單位服務(wù)成本高，所以，這樣加機(jī)器抗壓力成本太高，還得另外想招。
讀多寫少：緩存
緩存的理論依據(jù)是局部性原理。
一般系統(tǒng)的寫入請求遠(yuǎn)少于讀請求，針對寫少讀多的場景，很適合引入緩存集群。
在寫數(shù)據(jù)庫的時候同時寫一份數(shù)據(jù)到緩存集群里，然后用緩存集群來承載大部分的讀請求，因?yàn)榫彺婕汉苋菀鬃龅礁咝阅?，所以，這樣的話，通過緩存集群，就可以用更少的機(jī)器資源承載更高的并發(fā)。
緩存的命中率一般能做到很高，而且速度很快，處理能力也強(qiáng)（單機(jī)很容易做到幾萬并發(fā)），是理想的解決方案。
CDN本質(zhì)上就是緩存，被用戶大量訪問的靜態(tài)資源緩存在CDN中是目前的通用做法。
緩存也有很多需要謹(jǐn)慎處理的問題：
一致性問題：(a)更新db成功+更新cache失敗 -> 不一致 (b)更新db失敗+更新cache成功 -> 不一致 ?更新db成功+淘汰緩存失敗 -> 不一致
緩存穿透：查詢一定不存在的數(shù)據(jù)，會穿透緩存直接壓到數(shù)據(jù)庫，從而導(dǎo)致緩存失去作用，如果有人利用這個漏洞，大量查詢一定不存在的數(shù)據(jù)，會對數(shù)據(jù)庫造成壓力，甚至打掛數(shù)據(jù)庫。解決方案：布隆過濾器 或者 簡單的方案，查詢不存在的key，也把空結(jié)果寫入緩存（設(shè)置較短的過期淘汰時間），從而降低命失
緩存雪崩：如果大量緩存在一個時刻同時失效，則請求會轉(zhuǎn)到DB，則對DB形成壓迫，導(dǎo)致雪崩。簡單的解決方案是為緩存失效時間添加隨機(jī)值，降低同一時間點(diǎn)失效淘汰緩存數(shù)，避免集體失效事件發(fā)生
但緩存是針對讀，如果寫的壓力很大，怎么辦？
高寫入：消息中間件
同理，通過跟主庫加機(jī)器，耗費(fèi)的機(jī)器資源是很大的，這個就是數(shù)據(jù)庫系統(tǒng)的特點(diǎn)所決定的。
相同的資源下，數(shù)據(jù)庫系統(tǒng)太重太復(fù)雜，所以并發(fā)承載能力就在幾千/s的量級，所以此時你需要引入別的一些技術(shù)。
比如說消息中間件技術(shù)，也就是MQ集群，它是非常好的做寫請求異步化處理，實(shí)現(xiàn)削峰填谷的效果。
消息隊列能做解耦，在只需要最終一致性的場景下，很適合用來配合做流控。
假如說，每秒是1萬次寫請求，其中比如5千次請求是必須請求過來立馬寫入數(shù)據(jù)庫中的，但是另外5千次寫請求是可以允許異步化等待個幾十秒，甚至幾分鐘后才落入數(shù)據(jù)庫內(nèi)的。
那么此時完全可以引入消息中間件集群，把允許異步化的每秒5千次請求寫入MQ，然后基于MQ做一個削峰填谷。比如就以平穩(wěn)的1000/s的速度消費(fèi)出來然后落入數(shù)據(jù)庫中即可，此時就會大幅度降低數(shù)據(jù)庫的寫入壓力。
業(yè)界有很多著名的消息中間件，比如ZeroMQ，rabbitMQ，kafka等。
消息隊列本身也跟緩存系統(tǒng)一樣，可以用很少的資源支撐很高的并發(fā)請求，用它來支撐部分允許異步化的高并發(fā)寫入是很合適的，比使用數(shù)據(jù)庫直接支撐那部分高并發(fā)請求要減少很多的機(jī)器使用量。
避免擠兌：流控
再強(qiáng)大的系統(tǒng)，也怕流量短事件內(nèi)集中爆發(fā)，就像銀行怕擠兌一樣，所以，高并發(fā)另一個必不可少的模塊就是流控。
流控的關(guān)鍵是流控算法，有4種常見的流控算法。
計數(shù)器算法（固定窗口）：計數(shù)器算法是使用計數(shù)器在周期內(nèi)累加訪問次數(shù)，當(dāng)達(dá)到設(shè)定的限流值時，觸發(fā)限流策略，下一個周期開始時，進(jìn)行清零，重新計數(shù)，實(shí)現(xiàn)簡單。計數(shù)器算法方式限流對于周期比較長的限流，存在很大的弊端，有嚴(yán)重的臨界問題。
滑動窗口算法：將時間周期分為N個小周期，分別記錄每個小周期內(nèi)訪問次數(shù)，并且根據(jù)時間滑動刪除過期的小周期，當(dāng)滑動窗口的格子劃分的越多，那么滑動窗口的滾動就越平滑，限流的統(tǒng)計就會越精確。此算法可以很好的解決固定窗口算法的臨界問題。
漏桶算法：訪問請求到達(dá)時直接放入漏桶，如當(dāng)前容量已達(dá)到上限（限流值），則進(jìn)行丟棄（觸發(fā)限流策略）。漏桶以固定的速率進(jìn)行釋放訪問請求（即請求通過），直到漏桶為空。分布式環(huán)境下實(shí)施難度高。
令牌桶算法：程序以r（r=時間周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達(dá)時向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發(fā)限流策略。分布式環(huán)境下實(shí)施難度高。
4、高并發(fā)的實(shí)踐經(jīng)驗(yàn)
接入-邏輯-存儲是經(jīng)典的互聯(lián)網(wǎng)后端分層，但隨著業(yè)務(wù)規(guī)模的提高，邏輯層的復(fù)雜度也上升了，所以，針對邏輯層的架構(gòu)設(shè)計也出現(xiàn)很多新的技術(shù)和思路，常見的做法包括系統(tǒng)拆分，微服務(wù)。
除此之外，也有很多業(yè)界的優(yōu)秀實(shí)踐，包括某信服務(wù)器通過協(xié)程（無侵入，已開源libco）改造，極大的提高了系統(tǒng)的并發(fā)度和穩(wěn)定性，另外，緩存預(yù)熱，預(yù)計算，批量讀寫（減少IO），池技術(shù)等也廣泛應(yīng)用在實(shí)踐中，有效的提升了系統(tǒng)并發(fā)能力。
為了提升并發(fā)能力，邏輯后端對請求的處理，一般會用到生產(chǎn)者-消費(fèi)者多線程模型，即I/O線程負(fù)責(zé)網(wǎng)絡(luò)IO，協(xié)議編解碼，網(wǎng)絡(luò)字節(jié)流被解碼后產(chǎn)生的協(xié)議對象，會被包裝成task投入到task queue，然后worker線程會從該隊列取出task執(zhí)行，有些系統(tǒng)會用多進(jìn)程而非多線程，通過共享存儲，維護(hù)2個方向的shm queue，一個input q，一個output q，為了提高并發(fā)度，有時候會引入?yún)f(xié)程，協(xié)程是用戶線程態(tài)的多執(zhí)行流，它的切換成本更低，通常有更好的調(diào)度效率。
另外，構(gòu)建漏斗型業(yè)務(wù)或者系統(tǒng)，從客戶端請求到接入層，到邏輯層，到DB層，層層遞減，過濾掉請求，F(xiàn)ail Fast（盡早發(fā)現(xiàn)盡早過濾），嘴大小，哈哈。
漏斗型系統(tǒng)不僅僅是一個技術(shù)模型，它也可以是一個產(chǎn)品思維，配合產(chǎn)品的用戶分流，邏輯分離，可以構(gòu)建全方位的立體模型。
5、小結(jié)
莫讓浮云遮望眼，除去繁華識真顏。我們不能掌握了大方案，吹完了牛皮，而忽視了編程最本質(zhì)的東西，掌握最基本最核心的編程能力，比如數(shù)據(jù)架構(gòu)和算法，設(shè)計，慣用法，培養(yǎng)技術(shù)的審美，也是很重要的，既要致高遠(yuǎn)，又要盡精微。
關(guān)于數(shù)據(jù)庫的垂直分庫的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
創(chuàng)新互聯(lián)成都網(wǎng)站建設(shè)公司提供專業(yè)的建站服務(wù)，為您量身定制，歡迎來電（028-86922220）為您打造專屬于企業(yè)本身的網(wǎng)絡(luò)品牌形象。
成都創(chuàng)新互聯(lián)品牌官網(wǎng)提供專業(yè)的網(wǎng)站建設(shè)、設(shè)計、制作等服務(wù)，是一家以網(wǎng)站建設(shè)為主要業(yè)務(wù)的公司，在網(wǎng)站建設(shè)、設(shè)計和制作領(lǐng)域具有豐富的經(jīng)驗(yàn)。
網(wǎng)站欄目：垂直分庫：數(shù)據(jù)庫的優(yōu)化之路(數(shù)據(jù)庫的垂直分庫)
標(biāo)題路徑：http://www.dlmjj.cn/article/dpjsshh.html
