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