高并發(fā)下如何縮短響應(yīng)時(shí)間

1. http請(qǐng)求到達(dá)目標(biāo)網(wǎng)站服務(wù)器之前

2. http請(qǐng)求到達(dá)目標(biāo)網(wǎng)站服務(wù)器之后

如果忽略其中硬件部分和部分細(xì)節(jié)，請(qǐng)求一個(gè)網(wǎng)站數(shù)據(jù)的大體過程如下圖所示（其中CDN和緩存部分可以省略）：

我們要想縮短一個(gè)網(wǎng)站的響應(yīng)時(shí)間，本質(zhì)上是提高數(shù)據(jù)的返回速度，說的直白一點(diǎn)就是要把請(qǐng)求數(shù)據(jù)過程中的各個(gè)步驟提高速度，這樣整體下來響應(yīng)時(shí)間就會(huì)縮短。

把數(shù)據(jù)放在離用戶越近的地方響應(yīng)時(shí)間越快

客戶端

客戶端是發(fā)起一個(gè)網(wǎng)站請(qǐng)求的源頭，其實(shí)這個(gè)源頭可以施加一定的策略來大大縮短某些數(shù)據(jù)的獲取時(shí)間。其中最為常用的就是緩存，一些常用的，很少變動(dòng)的資源緩存在客戶端，不但能縮短獲取資源的時(shí)間，而且在很大程度上能減輕服務(wù)端的壓力。比如一些圖片，css，js文件，甚至一些接口的數(shù)據(jù)或者整個(gè)網(wǎng)頁內(nèi)容都可以在客戶端做緩存。另外http請(qǐng)求的合并也可以減少對(duì)服務(wù)端的請(qǐng)求次數(shù)，在一定程度上可以縮短請(qǐng)求的響應(yīng)時(shí)間。

DNS

一般網(wǎng)站的訪問方式都采用域名的方式（很少見IP方式），既然是域名就涉及到DNS解析速度的問題，如果DNS服務(wù)解析的速度比較慢，整體過程的響應(yīng)時(shí)間也會(huì)加長，不過這個(gè)過程其實(shí)很少出現(xiàn)慢的問題（不是說沒有）。

網(wǎng)絡(luò)

客戶端獲取到網(wǎng)站IP之后通過網(wǎng)卡把Http請(qǐng)求發(fā)送出去，目標(biāo)地址為相應(yīng)的網(wǎng)站服務(wù)器。在這個(gè)過程當(dāng)中如果客戶端和服務(wù)器端有一方帶寬比較小的話，就會(huì)加大響應(yīng)時(shí)間。我司曾經(jīng)就因?yàn)榉?wù)器帶寬過小導(dǎo)致客戶端響應(yīng)時(shí)間很長的情況，當(dāng)時(shí)排查了很長時(shí)間才發(fā)現(xiàn)。

當(dāng)然網(wǎng)絡(luò)是不可靠的，這個(gè)過程的響應(yīng)時(shí)間其實(shí)取決于很多因素，比如路由器的路由策略是否最優(yōu)，整個(gè)過程通過的網(wǎng)關(guān)數(shù)據(jù)量等。所以有很多網(wǎng)站其實(shí)是多地區(qū)多機(jī)房部署的，目的就是為了讓用戶通過很短的網(wǎng)絡(luò)路徑就能到達(dá)網(wǎng)站（其實(shí)這個(gè)過程運(yùn)營商的選擇也有影響）。

網(wǎng)站

當(dāng)一個(gè)請(qǐng)求到達(dá)網(wǎng)站服務(wù)器，服務(wù)器便開始處理請(qǐng)求，一般會(huì)有專門處理業(yè)務(wù)請(qǐng)求的一個(gè)業(yè)務(wù)層，有的體現(xiàn)為rpc協(xié)議的微服務(wù)，有的體現(xiàn)為簡(jiǎn)單的一個(gè)代碼分層。最終請(qǐng)求的數(shù)據(jù)會(huì)通過查詢數(shù)據(jù)庫來返回。其實(shí)這個(gè)過程和車站購票流程一樣，每個(gè)窗口的處理能力是有限的，對(duì)應(yīng)到服務(wù)器處理能力。由于這個(gè)原因，所以誕生了負(fù)載均衡的策略，核心思想就是：分。一臺(tái)服務(wù)器不夠，那就兩臺(tái)，三臺(tái)，四臺(tái)..... 直到并發(fā)的所有請(qǐng)求的響應(yīng)時(shí)間都在可控范圍之內(nèi)。

數(shù)據(jù)庫的情況類似，一個(gè)數(shù)據(jù)庫扛不住壓力，就加到N個(gè)數(shù)據(jù)庫分散壓力。一個(gè)表扛不住壓力，就把這個(gè)表拆分開，拆分成多個(gè)表，甚至拆分到多個(gè)不同服務(wù)器數(shù)據(jù)庫，這就是我們常用的拆表策略。有的時(shí)候在同一個(gè)數(shù)據(jù)庫中進(jìn)行表拆分，性能的提升并非大化，因?yàn)橐慌_(tái)服務(wù)器的磁盤IO是有上限的，就算拆成100個(gè)表，還是在同一個(gè)物理磁盤上，當(dāng)然這樣可緩解鎖單表的情況。

現(xiàn)在有很多的場(chǎng)景采用NOsql代替關(guān)系型數(shù)據(jù)庫來縮短響應(yīng)時(shí)間，在正常情況下，由于關(guān)系型數(shù)據(jù)庫的本身因素在特定場(chǎng)景下的讀寫速度比Nosql要慢很多，所以系統(tǒng)設(shè)計(jì)初期，可以考慮采用關(guān)系型數(shù)據(jù)庫和Nosql混用的方案。

緩存

當(dāng)并發(fā)的請(qǐng)求到達(dá)一定程度，瓶頸大部分情況下發(fā)生在DB層面，甚至DB無論怎么優(yōu)化總有上限。為了避免頻繁查詢數(shù)據(jù)庫產(chǎn)生瓶頸，誕生了緩存。在訪問數(shù)據(jù)庫之前加入了緩存層，當(dāng)然這里的緩存采用的方案在數(shù)據(jù)的響應(yīng)時(shí)間上要比數(shù)據(jù)庫小很多，比如常用的redis，Memcache，但是這些第三方的緩存組件還是要走網(wǎng)絡(luò)，比起進(jìn)程內(nèi)的緩存還是要慢的多。

現(xiàn)在一般流行的設(shè)計(jì)在網(wǎng)站層和服務(wù)層都有緩存策略，只不過緩存的數(shù)據(jù)和策略有所不同，但是最終目的都是為了加快請(qǐng)求的響應(yīng)。當(dāng)然加了緩存之后，數(shù)據(jù)的一致性需要仔細(xì)設(shè)計(jì)才可以，如果發(fā)生數(shù)據(jù)不一致的情況，程序員可能要背鍋了。

緩解數(shù)據(jù)庫壓力并不是引入緩存的唯一因素。

CDN加速

一些小廠可能用不到CDN，但是CDN帶來的加速還是很客觀的。CDN依靠部署在各地的邊緣服務(wù)器，通過中心平臺(tái)的負(fù)載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率。CDN就是把離用戶最近的數(shù)據(jù)返回給用戶。

寫在最后

程序異步化其實(shí)并不能縮短響應(yīng)時(shí)間，但是對(duì)提高吞吐量有很大作用。

網(wǎng)站名稱：高并發(fā)下如何縮短響應(yīng)時(shí)間
網(wǎng)站路徑：http://www.bm7419.com/news/101289.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、做網(wǎng)站、動(dòng)態(tài)網(wǎng)站、ChatGPT、外貿(mào)建站、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)