一文講清如何構(gòu)建高并發(fā)服務(wù)器

# 0、引言

軟件系統(tǒng)有三個(gè)追求：**高性能、高并發(fā)、高可用**，俗稱三高。三者既有區(qū)別也有聯(lián)系，門門道道很多，全面討論需要三天三夜，本篇討論高并發(fā)。

**高并發(fā)（High Concurrency）**。并發(fā)是操作系統(tǒng)領(lǐng)域的一個(gè)概念，指的是一段時(shí)間內(nèi)多任務(wù)流交替執(zhí)行的現(xiàn)象，后來這個(gè)概念被泛化，高并發(fā)用來指大流量、高請求的業(yè)務(wù)情景，比如春運(yùn)搶票，電商雙十一，秒殺大促等場景。

很多程序員每天忙著搬磚，平時(shí)接觸不到高并發(fā)，哪天受不了跑去面試，還常常會被面試官犀利的高并發(fā)問題直接KO，其實(shí)吧，高并發(fā)系統(tǒng)也不高深，我保證任何一個(gè)智商在線的看過這篇文章后，都能戰(zhàn)勝恐懼，重拾生活的信心。

# 1、高并發(fā)的度量指標(biāo)

既然是高并發(fā)系統(tǒng)，那并發(fā)一定要高，不然就名不副實(shí)。并發(fā)的指標(biāo)一般有**QPS、TPS、IOPS**，這幾個(gè)指標(biāo)都是可歸為**系統(tǒng)吞吐率**，QPS越高系統(tǒng)能hold住的請求數(shù)越多，但光關(guān)注這幾個(gè)指標(biāo)不夠，我們還需要關(guān)注RT，即響應(yīng)時(shí)間，也就是從發(fā)出request到收到response的時(shí)延，這個(gè)指標(biāo)跟吞吐往往是此消彼長的，我們追求的是一定時(shí)延下的高吞吐。

比如有100萬次請求，99萬次請求都在10毫秒內(nèi)響應(yīng)，其他次數(shù)10秒才響應(yīng)，平均時(shí)延不高，但時(shí)延高的用戶受不了，所以，就有了**TP90/TP99指標(biāo)**，這個(gè)指標(biāo)不是求平均，而是把時(shí)延從小到大排序，取排名90%/99%的時(shí)延，這個(gè)指標(biāo)越大，對慢請求越敏感。

除此之外，有時(shí)候，我們也會關(guān)注可用性指標(biāo)，這可歸到穩(wěn)定性。

一般而言，用戶感知友好的高并發(fā)系統(tǒng)，時(shí)延應(yīng)該控制在250毫秒以內(nèi)。

什么樣的系統(tǒng)才能稱為高并發(fā)？這個(gè)不好回答，因?yàn)樗Q于系統(tǒng)或者業(yè)務(wù)的類型。不過我可以告訴你一些眾所周知的指標(biāo)，這樣能幫助你下次在跟人扯淡的時(shí)候稍微靠點(diǎn)兒譜，不至于貽笑大方。

通常，數(shù)據(jù)庫單機(jī)每秒也就能抗住幾千這個(gè)量級，而做邏輯處理的服務(wù)單臺每秒抗幾萬、甚至幾十萬都有可能，而消息隊(duì)列等中間件單機(jī)每秒處理個(gè)幾萬沒問題，所以我們經(jīng)常聽到每秒處理數(shù)百萬、數(shù)千萬的消息中間件集群，而像阿某的API網(wǎng)關(guān)，每日百億請求也有可能。

# 2、高并發(fā)的設(shè)計(jì)思路

高并發(fā)的設(shè)計(jì)思路有兩個(gè)方向：

1. 垂直方向擴(kuò)展，也叫豎向擴(kuò)展

2. 水平方向擴(kuò)展，也叫橫向擴(kuò)展

## 垂直方向：提升單機(jī)能力

提升單機(jī)處理能力又可分為硬件和軟件兩個(gè)方面：

-?硬件方向，很好理解，花錢升級機(jī)器，更多核更高主頻更大存儲空間更多帶寬

-?軟件方向，包括用各快的數(shù)據(jù)結(jié)構(gòu)，改進(jìn)架構(gòu)，應(yīng)用多線程、協(xié)程，以及上性能優(yōu)化各種手段，但這玩意兒天花板低，就像提升個(gè)人產(chǎn)出一樣，996、007、最多24 X 7。

## 水平方向：分布式集群

為了解決分布式系統(tǒng)的復(fù)雜性問題，一般會用到**架構(gòu)分層和服務(wù)拆分**，通過分層做**隔離**，通過微服務(wù)**解耦**。

這個(gè)理論上沒有上限，只要做好層次和服務(wù)劃分，加機(jī)器擴(kuò)容就能滿足需求，但實(shí)際上并非如此，一方面分布式會增加系統(tǒng)復(fù)雜性，另一方面集群規(guī)模上去之后，也會引入一堆新問題。

因?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)顯然不能這么做，它肯定扛不住這個(gè)壓力，那一般的高并發(fā)系統(tǒng)是怎么做呢？比如某寶這樣的正經(jīng)系統(tǒng)是怎么處理高并發(fā)的呢？

其實(shí)大的思路都差不多，層次劃分 + 功能劃分?？梢园褜哟蝿澐掷斫鉃樗椒较虻膭澐?，而功能劃分理解為垂直方向的劃分。

首先，用戶不能直連服務(wù)器，要做分布式就要解決“分”的問題，有多個(gè)服務(wù)實(shí)例就需要做負(fù)載均衡，有不同服務(wù)類型就需要服務(wù)發(fā)現(xiàn)。

## 集群化：負(fù)載均衡

負(fù)載均衡就是把負(fù)載（request）均衡分配到不同的服務(wù)實(shí)例，利用集群的能力去對抗高并發(fā)，負(fù)載均衡是服務(wù)集群化的實(shí)施要素，它分3種：

1. **DNS負(fù)載均衡**，客戶端通過URL發(fā)起網(wǎng)絡(luò)服務(wù)請求的時(shí)候，會去DNS服務(wù)器做域名解釋，DNS會按一定的策略（比如就近策略）把URL轉(zhuǎn)換成IP地址，同一個(gè)URL會被解釋成不同的IP地址，這便是DNS負(fù)載均衡，它是一種粗粒度的負(fù)載均衡，它只用URL前半部分，因?yàn)镈NS負(fù)載均衡一般采用就近原則，所以通常能降低時(shí)延，但DNS有cache，所以也會更新不及時(shí)的問題。

2. **硬件負(fù)載均衡**，通過布置特殊的負(fù)載均衡設(shè)備到機(jī)房做負(fù)載均衡，比如F5，這種設(shè)備貴，性能高，可以支撐每秒百萬并發(fā)，還能做一些安全防護(hù)，比如防火墻。

3. **軟件負(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ā)的要求。

所以，我們需要做分庫分表 + 讀寫分離。

就是把一個(gè)庫分成多個(gè)庫，部署在多個(gè)數(shù)據(jù)庫服務(wù)上，主庫承載寫請求，從庫承載讀請求。從庫可以掛載多個(gè)，因?yàn)楹芏鄨鼍皩懙恼埱筮h(yuǎn)少于讀的請求，這樣就把對單個(gè)庫的壓力降下來了。

如果寫的請求上升就繼續(xù)分庫分表，如果讀的請求上升就掛更多的從庫，但數(shù)據(jù)庫天生不是很適合高并發(fā)，而且數(shù)據(jù)庫對機(jī)器配置的要求一般很高，導(dǎo)致單位服務(wù)成本高，所以，這樣加機(jī)器抗壓力成本太高，還得另外想招。

## 讀多寫少：緩存

緩存的理論依據(jù)是**局部性原理**。

一般系統(tǒng)的寫入請求遠(yuǎn)少于讀請求，針對寫少讀多的場景，很適合引入緩存集群。

在寫數(shù)據(jù)庫的時(shí)候同時(shí)寫一份數(shù)據(jù)到緩存集群里，然后用緩存集群來承載大部分的讀請求，因?yàn)榫彺婕汉苋菀鬃龅礁咝阅?，所以，這樣的話，通過緩存集群，就可以用更少的機(jī)器資源承載更高的并發(fā)。

緩存的命中率一般能做到很高，而且速度很快，處理能力也強(qiáng)（單機(jī)很容易做到幾萬并發(fā)），是理想的解決方案。

CDN本質(zhì)上就是緩存，被用戶大量訪問的靜態(tài)資源緩存在CDN中是目前的通用做法。

### 緩存也有很多需要謹(jǐn)慎處理的問題：

1. **一致性問題**：(a)更新db成功+更新cache失敗 -> 不一致 (b)更新db失敗+更新cache成功 -> 不一致 (c)更新db成功+淘汰緩存失敗 -> 不一致

2. **緩存穿透**：查詢一定不存在的數(shù)據(jù)，會穿透緩存直接壓到數(shù)據(jù)庫，從而導(dǎo)致緩存失去作用，如果有人利用這個(gè)漏洞，大量查詢一定不存在的數(shù)據(jù)，會對數(shù)據(jù)庫造成壓力，甚至打掛數(shù)據(jù)庫。解決方案：布隆過濾器 或者 簡單的方案，查詢不存在的key，也把空結(jié)果寫入緩存（設(shè)置較短的過期淘汰時(shí)間），從而降低命失

3. **緩存雪崩**：如果大量緩存在一個(gè)時(shí)刻同時(shí)失效，則請求會轉(zhuǎn)到DB，則對DB形成壓迫，導(dǎo)致雪崩。簡單的解決方案是為緩存失效時(shí)間添加隨機(jī)值，降低同一時(shí)間點(diǎn)失效淘汰緩存數(shù)，避免集體失效事件發(fā)生

但緩存是針對讀，如果寫的壓力很大，怎么辦？

## 高寫入：消息中間件

同理，通過跟主庫加機(jī)器，耗費(fèi)的機(jī)器資源是很大的，這個(gè)就是數(shù)據(jù)庫系統(tǒng)的特點(diǎn)所決定的。

相同的資源下，數(shù)據(jù)庫系統(tǒng)太重太復(fù)雜，所以并發(fā)承載能力就在幾千/s的量級，所以此時(shí)你需要引入別的一些技術(shù)。

比如說消息中間件技術(shù)，也就是MQ集群，它是非常好的做寫請求異步化處理，實(shí)現(xiàn)**削峰填谷**的效果。

消息隊(duì)列能做**解耦**，在只需要最終一致性的場景下，很適合用來配合做流控。

假如說，每秒是1萬次寫請求，其中比如5千次請求是必須請求過來立馬寫入數(shù)據(jù)庫中的，但是另外5千次寫請求是可以允許異步化等待個(gè)幾十秒，甚至幾分鐘后才落入數(shù)據(jù)庫內(nèi)的。

那么此時(shí)完全可以引入消息中間件集群，把允許異步化的每秒5千次請求寫入MQ，然后基于MQ做一個(gè)削峰填谷。比如就以平穩(wěn)的1000/s的速度消費(fèi)出來然后落入數(shù)據(jù)庫中即可，此時(shí)就會大幅度降低數(shù)據(jù)庫的寫入壓力。

業(yè)界有很多著名的消息中間件，比如ZeroMQ，rabbitMQ，kafka等。

消息隊(duì)列本身也跟緩存系統(tǒng)一樣，可以用很少的資源支撐很高的并發(fā)請求，用它來支撐部分允許異步化的高并發(fā)寫入是很合適的，比使用數(shù)據(jù)庫直接支撐那部分高并發(fā)請求要減少很多的機(jī)器使用量。

## 避免擠兌：流控

再強(qiáng)大的系統(tǒng)，也怕流量短事件內(nèi)集中爆發(fā)，就像銀行怕擠兌一樣，所以，高并發(fā)另一個(gè)必不可少的模塊就是流控。

流控的關(guān)鍵是流控算法，有4種常見的流控算法。

1. **計(jì)數(shù)器算法**（固定窗口）：計(jì)數(shù)器算法是使用計(jì)數(shù)器在周期內(nèi)累加訪問次數(shù)，當(dāng)達(dá)到設(shè)定的限流值時(shí)，觸發(fā)限流策略，下一個(gè)周期開始時(shí)，進(jìn)行清零，重新計(jì)數(shù)，實(shí)現(xiàn)簡單。計(jì)數(shù)器算法方式限流對于周期比較長的限流，存在很大的弊端，有嚴(yán)重的臨界問題。

2. **滑動窗口算法**：將時(shí)間周期分為N個(gè)小周期，分別記錄每個(gè)小周期內(nèi)訪問次數(shù)，并且根據(jù)時(shí)間滑動刪除過期的小周期，當(dāng)滑動窗口的格子劃分的越多，那么滑動窗口的滾動就越平滑，限流的統(tǒng)計(jì)就會越精確。此算法可以很好的解決固定窗口算法的臨界問題。

3. **漏桶算法**：訪問請求到達(dá)時(shí)直接放入漏桶，如當(dāng)前容量已達(dá)到上限（限流值），則進(jìn)行丟棄（觸發(fā)限流策略）。漏桶以固定的速率進(jìn)行釋放訪問請求（即請求通過），直到漏桶為空。分布式環(huán)境下實(shí)施難度高。

4. **令牌桶算法**：程序以r（r=時(shí)間周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達(dá)時(shí)向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發(fā)限流策略。分布式環(huán)境下實(shí)施難度高。

# 4、高并發(fā)的實(shí)踐經(jīng)驗(yàn)

接入-邏輯-存儲是經(jīng)典的互聯(lián)網(wǎng)后端分層，但隨著業(yè)務(wù)規(guī)模的提高，邏輯層的復(fù)雜度也上升了，所以，針對邏輯層的架構(gòu)設(shè)計(jì)也出現(xiàn)很多新的技術(shù)和思路，常見的做法包括系統(tǒng)拆分，微服務(wù)。

除此之外，也有很多業(yè)界的優(yōu)秀實(shí)踐，包括某信服務(wù)器通過協(xié)程（無侵入，已開源libco）改造，極大的提高了系統(tǒng)的并發(fā)度和穩(wěn)定性，另外，緩存預(yù)熱，預(yù)計(jì)算，批量讀寫（減少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線程會從該隊(duì)列取出task執(zhí)行，有些系統(tǒng)會用多進(jìn)程而非多線程，通過共享存儲，維護(hù)2個(gè)方向的shm queue，一個(gè)input q，一個(gè)output q，為了提高并發(fā)度，有時(shí)候會引入?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)不僅僅是一個(gè)技術(shù)模型，它也可以是一個(gè)**產(chǎn)品思維**，配合產(chǎn)品的用戶分流，邏輯分離，可以構(gòu)建全方位的立體模型。

# 5、小結(jié)

莫讓浮云遮望眼，除去繁華識真顏。我們不能掌握了大方案，吹完了牛皮，而忽視了**編程最本質(zhì)的東西，掌握最基本最核心的編程能力**，比如數(shù)據(jù)架構(gòu)和算法，設(shè)計(jì)，慣用法，培養(yǎng)技術(shù)的審美，也是很重要的，**既要致高遠(yuǎn)，又要盡精微**。

軟件開發(fā) 架構(gòu)設(shè)計(jì) 云計(jì)算

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。