建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「跨界架構(gòu)師」，作者Zachary。轉(zhuǎn)載本文請(qǐng)聯(lián)系跨界架構(gòu)師公眾號(hào)。
大家好，我是Z哥。
最近正好在編寫(xiě)一套新的面試題，其中有一道是與高并發(fā)相關(guān)的。出題的目的是想了解一下候選人面對(duì)大流量場(chǎng)景下的優(yōu)化思路。在出這道題的過(guò)程中，我自己也梳理了一下自己對(duì)這個(gè)問(wèn)題的思路。
然后之所以想在這里分享出來(lái)，是因?yàn)檫@是我這些年經(jīng)過(guò)實(shí)戰(zhàn)所得出的躺著“血汗”的經(jīng)驗(yàn)，所以我覺(jué)得這可能對(duì)很多讀者都有所幫助。
不過(guò)丑話說(shuō)在前面，我的思路并不是完美的，畢竟條條大路通羅馬，解決「高并發(fā)」的思路也有很多種。所以歡迎大家在評(píng)論區(qū)分享你的看法。
/01 高并發(fā)的定義/
首先，高并發(fā)的定義是什么?
高并發(fā)意味著大流量，需要運(yùn)用技術(shù)手段抵抗流量的沖擊。這些手段的效果好比你可以操縱流量，讓流量可以乖乖地按照你的期望、更平穩(wěn)地被系統(tǒng)所處理，帶給用戶更好的體驗(yàn)。對(duì)，就和大禹治水那樣。
我想，幾乎每個(gè)程序員心里都有過(guò)一個(gè)疑問(wèn)，達(dá)到多少Q(mào)PS或者TPS才算是高并發(fā)?
其實(shí)，這個(gè)問(wèn)題無(wú)法單純地通過(guò)一個(gè)統(tǒng)一標(biāo)準(zhǔn)的數(shù)字來(lái)判斷。因?yàn)椴煌臉I(yè)務(wù)所對(duì)應(yīng)的復(fù)雜度不同，不能一概而論。
我自己用的評(píng)判標(biāo)準(zhǔn)是，當(dāng)一個(gè)運(yùn)行正常的系統(tǒng)在沒(méi)有刻意優(yōu)化性能的情況下，出現(xiàn)了性能問(wèn)題，說(shuō)明他開(kāi)始進(jìn)入到高并發(fā)的范圍了。
對(duì)，就是這么簡(jiǎn)單粗暴，沒(méi)有具體的數(shù)字。
但是在高并發(fā)是常態(tài)的場(chǎng)景中，一般都會(huì)有一個(gè)監(jiān)控系統(tǒng)，會(huì)持續(xù)觀察至少以下這幾個(gè)指標(biāo)是否正常。
- TPS。每秒事務(wù)處理量，這里的事務(wù)是指一個(gè)客戶機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過(guò)程。(以客戶端為視角)
- QPS。每秒查詢率，可以通過(guò)并發(fā)量 / 平均響應(yīng)時(shí)間計(jì)算得出。(以服務(wù)端為視角，一個(gè)TPS可能會(huì)對(duì)應(yīng)多個(gè)QPS)
- 并發(fā)用戶數(shù)。系統(tǒng)可以同時(shí)承載的正常使用系統(tǒng)功能的用戶的數(shù)量。
- 響應(yīng)時(shí)間。很多時(shí)候也叫RT，是指系統(tǒng)對(duì)請(qǐng)求作出響應(yīng)的時(shí)間。
- 帶寬。如果是一個(gè)數(shù)據(jù)傳輸量比較大的業(yè)務(wù)，還需要考慮帶寬問(wèn)題，比如視頻、音頻類(lèi)應(yīng)用程序。
如果你連這些指標(biāo)的含義都不是很清楚，那就多讀幾遍，先搞清楚它們，否則你的高并發(fā)是閉著眼睛在做。
/02 應(yīng)對(duì)高并發(fā)的思路/
很多缺乏經(jīng)驗(yàn)的小伙伴，遇到高并發(fā)問(wèn)題，不管三七二十一，上來(lái)就懟緩存。
用緩存是沒(méi)錯(cuò)的，但是緩存也不是靈丹妙藥，在哪里都適合。畢竟，緩存是「有狀態(tài)」的，在軟件開(kāi)發(fā)中，處理「有狀態(tài)」的東西總是比「無(wú)狀態(tài)」的麻煩得多，因?yàn)榇嬖跀?shù)據(jù)一致性的問(wèn)題需要考慮。
我建議你按照以下三個(gè)步驟來(lái)考慮這個(gè)問(wèn)題。
01 梳理請(qǐng)求流轉(zhuǎn)鏈路
梳理好了請(qǐng)求流轉(zhuǎn)的鏈路，就好比你手里有了一張“作戰(zhàn)地圖”，你可以更加直觀、準(zhǔn)確地進(jìn)行排兵布陣。
畢竟軟件開(kāi)發(fā)本身就是一個(gè)工程的問(wèn)題，我們不能憑感覺(jué)，拍腦袋去做事。解決高并發(fā)問(wèn)題自然也不例外。
02 確定目標(biāo)
有一句話說(shuō)得好，“沒(méi)有最好，只有更好”。如果不先確定目標(biāo)，這件事將會(huì)變成對(duì)性能無(wú)止境地追求。而過(guò)度的高性能，不但不會(huì)產(chǎn)生額外的收益，反而是對(duì)投入成本的浪費(fèi)，畢竟資源是有代價(jià)的，而且是有限的。
我建議你將具體的數(shù)值目標(biāo)細(xì)化到每一個(gè) API 上。比如我一般會(huì)先確定整個(gè)業(yè)務(wù)線的 TPS 要達(dá)到多少。例如，下單的 TPS 要達(dá)到100。
接下來(lái)，我會(huì)根據(jù)前面梳理好的鏈路圖，得到其中會(huì)涉及到哪些 Service ，哪些 API ，有哪些 API 還會(huì)被不同的 Service 多次調(diào)用的。
然后會(huì)根據(jù)鏈路中 API 被調(diào)用的先后順序(一般越上游的 API 定的數(shù)值要適當(dāng)放大)以及會(huì)被重復(fù)調(diào)用的次數(shù)，得到每個(gè) API 的 QPS 目標(biāo)。比如，
- 獲取購(gòu)物車(chē)列表，存在兩次調(diào)用，QPS = 200。
- 批量獲取商品庫(kù)存，存在三次調(diào)用，QPS = 300。
- 獲取會(huì)員信息，存在一次調(diào)用，QPS = 100。
- ……
照著這個(gè)思路，把所有業(yè)務(wù)線中會(huì)涉及到的 API 的 QPS 都確定好，然后將相同 API 的 QPS 數(shù)值相加，就能得到在整個(gè)系統(tǒng)層面每個(gè) API 的理想 QPS 數(shù)值(相當(dāng)于是在各條業(yè)務(wù)線都達(dá)到預(yù)估峰值的情況下)。比如，
- 獲取購(gòu)物車(chē)列表，出現(xiàn)在三個(gè)業(yè)務(wù)線，QPS = 200 + 500 + 100 = 800。
- 批量獲取商品庫(kù)存，出現(xiàn)在兩個(gè)業(yè)務(wù)線，QPS = 300 + 200 = 500。
- 獲取會(huì)員信息，出現(xiàn)在兩個(gè)業(yè)務(wù)線，QPS = 100 + 200 = 300。
- ……
當(dāng)然了，實(shí)際制定的目標(biāo)除了 QPS 以外，還有其它指標(biāo)，上面只是舉個(gè)例子。
另外，需要額外注意的是，要關(guān)注 TP90、TP99 的「響應(yīng)時(shí)間」。因?yàn)榫退闫骄憫?yīng)時(shí)間達(dá)標(biāo)了，也不代表整個(gè)系統(tǒng)很穩(wěn)定。因?yàn)榭赡艽嬖?0%的請(qǐng)求響應(yīng)速度特別快，把平均值拉低了，但是同時(shí)還存在大量的耗時(shí)特別嚴(yán)重的請(qǐng)求。我慣用的經(jīng)驗(yàn)是，如果TP99超過(guò)了平均值的一倍，就需要引起重視了，因?yàn)檫@意味著某個(gè)地方存在著明顯的性能瓶頸。
03 制定具體的優(yōu)化方案
其實(shí)具體的優(yōu)化方案有很多種，要根據(jù)實(shí)際的情況來(lái)選擇。不過(guò)具體怎么選擇，還是需要你有全局視野。因?yàn)檎麄€(gè)系統(tǒng)是一體的，通過(guò)相互配合形成合力，可以大大降低優(yōu)化的難度。比如，選擇某個(gè)優(yōu)化方案后，上游的 API 能扛掉90%的流量不往下游請(qǐng)求，那么下游 API 的 QPS 目標(biāo)也可以適當(dāng)降低了。
以下就是我綜合復(fù)雜度和成本所排列的具體方案，從簡(jiǎn)單到復(fù)雜。
- 先在代碼層面做優(yōu)化，比如代碼性能，多線程，請(qǐng)求合并，池化(連接池、線程池、對(duì)象池等等)。
- 能升級(jí)硬件的就升級(jí)硬件。
- 能用緩存解決的堅(jiān)決不做系統(tǒng)拆分。并且，緩存盡可能做到上游。比如， cdn >頁(yè)面> api > service 。
- 如果在數(shù)據(jù)處理上產(chǎn)生瓶頸，那么優(yōu)先考慮業(yè)務(wù)上是否接受異步，如果接受，那么用 MQ 來(lái)削峰填谷?；蛘呦蘖鹘导?jí)。
- 如果 MQ 也不頂用，是整體吞吐量上的瓶頸的話，只要不是寫(xiě)數(shù)據(jù)的瓶頸，盡量通過(guò)程序拆分而不是數(shù)據(jù)庫(kù)拆分來(lái)解決問(wèn)題。(此時(shí)需要引入服務(wù)治理，另外，會(huì)存在一致性問(wèn)題，數(shù)據(jù)合并問(wèn)題要解決)
- 非得動(dòng)到數(shù)據(jù)層面的話，優(yōu)先考慮數(shù)據(jù)庫(kù)讀寫(xiě)分離，而不是直接拆分?jǐn)?shù)據(jù)。
- 實(shí)在迫不得已需要拆分?jǐn)?shù)據(jù)，優(yōu)先考慮根據(jù)業(yè)務(wù)垂直拆分，而不是水平拆分。(水平拆分的數(shù)據(jù)合并代價(jià)會(huì)比垂直拆分更大)
- 最后才是數(shù)據(jù)庫(kù)水平拆分，支持無(wú)限擴(kuò)容，一勞永逸。
你看，雖然方案有很多，但是你也能觀察到一些規(guī)律：越在上游解決問(wèn)題，成本越低。所以，以漏斗思維來(lái)做全局的考慮是最適合不過(guò)的。從客戶端請(qǐng)求到接入層，到邏輯層，到 DB 層，層層遞減，過(guò)濾掉請(qǐng)求，哪怕是出現(xiàn)異常也要 Fail Fast(要失敗也要盡早返回)。
/03 落地/
真正落地的時(shí)候，涉及到的具體技術(shù)細(xì)節(jié)就多了，負(fù)載均衡啊、緩存啊、消息隊(duì)列啊、分庫(kù)分表啊等等。我這里就不展開(kāi)了，每一點(diǎn)展開(kāi)都要寫(xiě)好多。有興趣的小伙伴可以移步我之前寫(xiě)的分布式系統(tǒng)系列文章——《8個(gè)月打磨，一份送給程序員的「分布式系統(tǒng)」合集》
其實(shí)，真正要把高并發(fā)當(dāng)作一個(gè)系統(tǒng)化的事情來(lái)看待，視野不能僅僅局限在「性能」這一個(gè)維度上，還至少需要考慮「可用性」和「擴(kuò)展性」這兩個(gè)方面。
可用性就是系統(tǒng)可以正常服務(wù)的時(shí)間。一個(gè)雖然訪問(wèn)速度沒(méi)那么快，但是全年不停機(jī)、無(wú)故障;另一個(gè)雖然訪問(wèn)速度很快，但是隔三差五出現(xiàn)上事故、宕機(jī)，用戶肯定選擇前者。
擴(kuò)展性表示系統(tǒng)的快速擴(kuò)展能力，當(dāng)遇到突發(fā)的大流量沖擊時(shí)，能否在短時(shí)間內(nèi)完成擴(kuò)容，以承接這部分流量。比如，雙11活動(dòng)、明星熱搜等場(chǎng)景。畢竟，我們不可能準(zhǔn)確地預(yù)測(cè)未來(lái)的流量一定在什么范圍內(nèi)，也更加不可能隨時(shí)為它準(zhǔn)備著大量冗余的資源。
所以，這三個(gè)目標(biāo)是需要通盤(pán)考慮的，因?yàn)樗鼈兓ハ嚓P(guān)聯(lián)、甚至相互影響。
比如，當(dāng)你考慮系統(tǒng)擴(kuò)展能力的時(shí)候，你會(huì)將服務(wù)設(shè)計(jì)成無(wú)狀態(tài)的，這種設(shè)計(jì)其實(shí)不但提高了可擴(kuò)展性，其實(shí)也間接提升了系統(tǒng)的性能和可用性，因?yàn)槟憧梢噪S時(shí)橫向擴(kuò)展。
再比如，為了提高可用性，通常會(huì)對(duì)服務(wù)接口進(jìn)行超時(shí)設(shè)置，以防大量線程阻塞在慢請(qǐng)求上造成系統(tǒng)雪崩。具體超時(shí)時(shí)間的設(shè)置成多少，參考的就是 API 的性能表現(xiàn)。
好了，總結(jié)一下。
這篇呢Z哥和你分享了我對(duì)高并發(fā)問(wèn)題的處理思路。
按照以下三個(gè)步驟進(jìn)行。
梳理請(qǐng)求流轉(zhuǎn)鏈路
確定目標(biāo)
制定具體的優(yōu)化方案
其中的第2和3點(diǎn)在文中給了很多實(shí)操細(xì)節(jié)，這里就不一一羅列了。
希望對(duì)你有所幫助。
業(yè)務(wù)都是從0到1做起來(lái)的，在業(yè)務(wù)量逐漸變成原來(lái)的10倍、100倍的過(guò)程中，你是否用到了高并發(fā)的處理思路去演進(jìn)你的系統(tǒng)，從架構(gòu)設(shè)計(jì)、編碼實(shí)現(xiàn)、甚至產(chǎn)品方案等維度去預(yù)防和解決高并發(fā)的問(wèn)題?
本文名稱(chēng)：應(yīng)對(duì)「高并發(fā)」的思路
網(wǎng)頁(yè)URL：http://m.fisionsoft.com.cn/article/coihioc.html
