剛?cè)腴T的產(chǎn)品經(jīng)理經(jīng)常會(huì)聽到前輩們說(shuō)應(yīng)該懂點(diǎn)技術(shù)，卻不明白為什么。本文作者分享了幾個(gè)被迫妥協(xié)的產(chǎn)品設(shè)計(jì)的例子，希望能讓不是技術(shù)出身的產(chǎn)品經(jīng)理了解到“產(chǎn)品經(jīng)理應(yīng)該懂點(diǎn)技術(shù)”在產(chǎn)品設(shè)計(jì)中有什么指導(dǎo)意義，一起來(lái)看一下吧。

剛?cè)腴T的產(chǎn)品經(jīng)理經(jīng)常聽前輩們或者網(wǎng)上的產(chǎn)品“專家”們說(shuō)應(yīng)該懂點(diǎn)技術(shù)，這個(gè)說(shuō)要懂點(diǎn)前端技術(shù)，那個(gè)說(shuō)要懂點(diǎn)后端技術(shù)，有的說(shuō)要懂點(diǎn)數(shù)據(jù)庫(kù)，也有的說(shuō)要了解服務(wù)器，搞得他們覺得在成為產(chǎn)品經(jīng)理之前，應(yīng)該先成為一個(gè)全棧工程師。

現(xiàn)在產(chǎn)品經(jīng)理的門檻越來(lái)越低，一方面，市場(chǎng)上的產(chǎn)品越來(lái)越多，同質(zhì)化也越來(lái)越嚴(yán)重，有時(shí)候產(chǎn)品經(jīng)理只要稍加借鑒就可以做出不錯(cuò)的交互設(shè)計(jì)，雖然有時(shí)候他們未必清楚為什么要這么設(shè)計(jì)；另一方面，產(chǎn)品經(jīng)理在設(shè)計(jì)上對(duì)技術(shù)不友好的地方往往會(huì)在技術(shù)評(píng)審中被指出，并按研發(fā)工程師的要求進(jìn)行調(diào)整，所以有些即使完全不懂技術(shù)的產(chǎn)品經(jīng)理，一樣能夠很好地完成工作。

下文分享的幾個(gè)小案例，希望能夠讓不是技術(shù)出身的產(chǎn)品經(jīng)理了解到“產(chǎn)品經(jīng)理應(yīng)該懂點(diǎn)技術(shù)”到底在產(chǎn)品設(shè)計(jì)中有什么指導(dǎo)意義。

我們?nèi)粘Ｊ褂密浖a(chǎn)品的時(shí)候，其實(shí)都是在跟服務(wù)器資源進(jìn)行交互，大致的過(guò)程是這樣的：

當(dāng)我們?cè)谠L問(wèn)載體（瀏覽器、APP或者小程序中）進(jìn)行某個(gè)操作（如點(diǎn)擊按鈕），這個(gè)時(shí)候會(huì)向服務(wù)器發(fā)送請(qǐng)求（請(qǐng)求的內(nèi)容由具體的操作所決定），服務(wù)器在收到后，將請(qǐng)求對(duì)應(yīng)的內(nèi)容“響應(yīng)”回來(lái)，這時(shí)訪問(wèn)載體再將響應(yīng)的內(nèi)容“渲染”出來(lái)，就完成了一次資源交互。

你可以把服務(wù)器想象成一個(gè)虛擬的商家，經(jīng)營(yíng)著各種商品，而我們請(qǐng)求的過(guò)程，就是告訴商家我們需要的商品，商家根據(jù)我們的需求給我們提供商品。

上面的過(guò)程你可以這么理解：你告訴（發(fā)送請(qǐng)求）商家（服務(wù)器），說(shuō)你需要一個(gè)蘋果（請(qǐng)求信息），商家接到信息后，把蘋果給你（響應(yīng)）。

下文的案例需要你先能夠理解上述的原理。

一、分頁(yè)

分頁(yè)設(shè)計(jì)在軟件產(chǎn)品中隨處可見，下圖是一個(gè)最基礎(chǔ)的分頁(yè)器，支持上一頁(yè)、下一頁(yè)以及跳轉(zhuǎn)到指定頁(yè)的操作。

分頁(yè)本身是一個(gè)妥協(xié)的設(shè)計(jì)，如果數(shù)據(jù)少，沒(méi)有必要分頁(yè)，如果數(shù)據(jù)多，分頁(yè)也沒(méi)有用，基本靠搜索，你可以想想平時(shí)在分頁(yè)器上用得最多的，是不是就是“下一頁(yè)”？

有些信息流的頁(yè)面對(duì)分頁(yè)的功能做了調(diào)整，如下圖一樣，只剩下一個(gè)“下一頁(yè)”（加載更多）的操作，每次點(diǎn)擊加載一頁(yè)數(shù)據(jù)，之前已經(jīng)加載的數(shù)據(jù)仍保留在頁(yè)面上，這種技術(shù)，叫做“懶加載”。

后來(lái)，為了方便用戶，“懶加載”又演變出一種新的交互形式，就是當(dāng)列表快翻到頁(yè)尾的時(shí)候，頁(yè)面就自動(dòng)進(jìn)行“懶加載”，在用戶看來(lái)，就好像沒(méi)有了翻頁(yè)的操作。

即使是“懶加載”，本質(zhì)上還是需要翻頁(yè)，只是弱化了用戶對(duì)分頁(yè)操作的感知，為什么不直接將全部?jī)?nèi)容顯示出來(lái)？分頁(yè)的意義在哪里？

你可以想象，如果你跟商家購(gòu)買1噸的蘋果，并要求商家將這噸蘋果一次性放入你的倉(cāng)庫(kù)，商家裝箱需要時(shí)間，運(yùn)輸需要時(shí)間，到達(dá)目的地卸貨也需要時(shí)間，而因?yàn)樨浳锾啵@幾個(gè)時(shí)間加起來(lái)都非常長(zhǎng)，其中任何一個(gè)環(huán)節(jié)出現(xiàn)問(wèn)題都有可能導(dǎo)致你收到的蘋果貨不對(duì)板，比如商家裝箱工人不足，處理不了這么多蘋果的裝箱工作；比如運(yùn)輸時(shí)間太長(zhǎng)，過(guò)程中蘋果腐爛或遺失；比如到達(dá)目的地發(fā)現(xiàn)倉(cāng)庫(kù)太小，容納不了這么多蘋果入庫(kù)。

從技術(shù)上來(lái)講，就是當(dāng)你發(fā)送請(qǐng)求時(shí)，如果請(qǐng)求到的數(shù)據(jù)量很大，服務(wù)器處理大量數(shù)據(jù)可能會(huì)“超時(shí)”，數(shù)據(jù)傳輸過(guò)程中“失真”風(fēng)險(xiǎn)增加，訪問(wèn)載體加載大量數(shù)據(jù)時(shí)可能出現(xiàn)“假死”甚至“崩潰”的現(xiàn)象，這些都可能導(dǎo)致你無(wú)法獲取到完整的信息。

分頁(yè)，就能解決這樣的問(wèn)題。

首先，服務(wù)器收到請(qǐng)求后，只響應(yīng)1頁(yè)數(shù)據(jù)（具體1頁(yè)多少條數(shù)據(jù)由分頁(yè)邏輯決定），這個(gè)時(shí)候傳輸?shù)臄?shù)據(jù)量很小，如果用戶想要看更多內(nèi)容，就可以通過(guò)分頁(yè)器來(lái)選擇下一頁(yè)或跳轉(zhuǎn)到指定頁(yè)，當(dāng)用戶通過(guò)分頁(yè)器發(fā)送指令之后，服務(wù)器再根據(jù)指令返回對(duì)應(yīng)頁(yè)的數(shù)據(jù)，這樣，從“全量供應(yīng)”變成了“按需供應(yīng)”，減少了每次傳輸?shù)臄?shù)據(jù)量，不僅從等待的時(shí)間上改善了用戶體驗(yàn)，也減輕了服務(wù)器的負(fù)擔(dān)。

分頁(yè)就好比你跟商家說(shuō)要1噸蘋果，商家說(shuō)沒(méi)問(wèn)題，但每次只給你100斤，等你需要更多的時(shí)候，你再跟商家說(shuō)，商家再給你100斤，直到1噸蘋果全部給完為止，這樣可以減輕商家的負(fù)擔(dān)，縮短運(yùn)輸時(shí)間，降低運(yùn)輸風(fēng)險(xiǎn)，也可以給倉(cāng)庫(kù)留夠余量。

現(xiàn)在很多分頁(yè)器會(huì)提供每頁(yè)顯示多少條數(shù)據(jù)的操作，這就好比你可以告訴商家每次給你提供多少斤蘋果，這種方式方便了用戶自定義單次請(qǐng)求的數(shù)據(jù)量，又同時(shí)將單次請(qǐng)求的最大數(shù)據(jù)量控制在系統(tǒng)能夠穩(wěn)定處理的范圍內(nèi)。但說(shuō)到底，它始終都是被迫妥協(xié)做出來(lái)的產(chǎn)品設(shè)計(jì)。

二、實(shí)時(shí)搜索

實(shí)時(shí)搜索并不是被迫妥協(xié)的設(shè)計(jì)，相反，它是一個(gè)對(duì)用戶非常友好，體驗(yàn)極佳的設(shè)計(jì)。

實(shí)時(shí)搜索是什么，是當(dāng)我們提供搜索條件的時(shí)候，系統(tǒng)根據(jù)搜索條件實(shí)時(shí)匹配內(nèi)容。如上圖所示，當(dāng)我們輸入關(guān)鍵詞時(shí)，系統(tǒng)就自動(dòng)查詢出匹配的結(jié)果。

可是這個(gè)設(shè)計(jì)，卻并非在產(chǎn)品設(shè)計(jì)中隨處可見，在系統(tǒng)設(shè)計(jì)中，更多的是像下圖所示這樣輸入關(guān)鍵詞之后手動(dòng)觸發(fā)查詢。為什么實(shí)時(shí)搜索不能在產(chǎn)品設(shè)計(jì)中普及，而被迫妥協(xié)采用這樣的設(shè)計(jì)呢。

首先我們要知道，實(shí)時(shí)搜索的每一次請(qǐng)求都可能是一次關(guān)鍵詞不精準(zhǔn)或不完整的查詢，最終的結(jié)果可能是經(jīng)過(guò)多輪查詢后得到的，而手動(dòng)觸發(fā)搜索在關(guān)鍵詞足夠準(zhǔn)確的情況下，只需要通過(guò)一輪查詢就能得到最終結(jié)果。

還是那個(gè)蘋果的例子，實(shí)時(shí)查詢等于你先告訴商家你需要蘋果，這個(gè)時(shí)候商家馬上要給你做出回應(yīng)，但是“蘋果”這個(gè)詞太籠統(tǒng)了，你到底是要蘋果手機(jī)還是可以吃的蘋果，商家也不清楚，所以只能將所有符合條件的商品都給你；這個(gè)時(shí)候你又向商家追加了關(guān)鍵詞“新疆”，商家猜測(cè)，你應(yīng)該是想要購(gòu)買產(chǎn)地是新疆的蘋果；最后你又追加了關(guān)鍵詞“包郵”，此時(shí)商家重新在所有產(chǎn)地為新疆的蘋果中找出支持包郵的。而手動(dòng)觸發(fā)搜索等于你直接告訴商家“蘋果新疆包郵”，商家直接根據(jù)你的要求給你找出符合條件的結(jié)果。

從上述的例子我們可以看到，實(shí)時(shí)搜索查詢請(qǐng)求次數(shù)更多，對(duì)服務(wù)器的資源消耗也更大，除了服務(wù)端的壓力，前端訪問(wèn)載體需要在短時(shí)間內(nèi)多次渲染查詢結(jié)果，一邊查詢一邊渲染，可能會(huì)造成頁(yè)面卡頓等體驗(yàn)不好的結(jié)果。

相比之下，要完成相同關(guān)鍵詞的搜索，手動(dòng)觸發(fā)查詢只需要進(jìn)行一次查詢和一次渲染就完成了，對(duì)服務(wù)器和訪問(wèn)載體更加友好。

你可能會(huì)以為手動(dòng)觸發(fā)搜索是為了避免實(shí)時(shí)搜索帶來(lái)的頻繁請(qǐng)求而造成服務(wù)器和訪問(wèn)端的壓力，被迫妥協(xié)而誕生，而實(shí)際上，查詢最早就是以手動(dòng)觸發(fā)查詢的形式存在的，而實(shí)時(shí)搜索因?yàn)轶w驗(yàn)更加優(yōu)秀而誕生，并在特定的場(chǎng)景下被使用。

什么情況下可以采用實(shí)時(shí)搜索設(shè)計(jì)呢？

1）數(shù)據(jù)體量小且增長(zhǎng)可控或不會(huì)增長(zhǎng)

比如國(guó)家的行政區(qū)劃數(shù)據(jù)，數(shù)量級(jí)不會(huì)很大，且不會(huì)動(dòng)不動(dòng)就增加幾十個(gè)省份或幾百個(gè)城市的數(shù)據(jù)。

2）查詢條件相對(duì)單一

現(xiàn)在有很多平臺(tái)有聚合搜索的功能，一個(gè)輸入框可以查詢數(shù)據(jù)庫(kù)的 N 個(gè)字段，這種如果做實(shí)時(shí)搜索服務(wù)器壓力將非常大。

3）前端二次查詢

查詢是訪問(wèn)端發(fā)送關(guān)鍵詞到服務(wù)端，服務(wù)端返回結(jié)果的過(guò)程，但有時(shí)候我們還會(huì)在拿到服務(wù)端的查詢結(jié)果的情況下，直接在訪問(wèn)端做二次查詢。比如我向服務(wù)端查詢廣東的城市，服務(wù)端返回了廣東的所有城市名稱，這個(gè)時(shí)候如果我想查詢這些城市里面有沒(méi)有我要找的，就可以在訪問(wèn)端做二次查詢，由于結(jié)果已經(jīng)事先從服務(wù)端拿到，現(xiàn)在是對(duì)結(jié)果進(jìn)行二次查詢，無(wú)需再次請(qǐng)求服務(wù)器，在這種情況下，也可以做實(shí)時(shí)搜索。

三、進(jìn)度條 與 Loading

進(jìn)度條是偉大的設(shè)計(jì)；比進(jìn)度條更偉大的設(shè)計(jì)是進(jìn)度條百分比，這個(gè)我們?cè)谏蟼鲿r(shí)經(jīng)?？吹?；比進(jìn)度條百分比更偉大的設(shè)計(jì)是進(jìn)度完成剩余時(shí)間，這個(gè)我們?cè)谙螺d時(shí)經(jīng)?？吹?。

但等待的時(shí)間并不總是以進(jìn)度條的形式出現(xiàn)，有時(shí)候陪伴我們度過(guò)等待時(shí)光的，叫做——Loading。

如果說(shuō)，進(jìn)度條卡在99.9%是一個(gè)令人抓狂的時(shí)間點(diǎn)，那么 Loading 動(dòng)畫出現(xiàn)時(shí)，就是另一個(gè)令人抓狂的時(shí)間點(diǎn)。當(dāng) Loading 動(dòng)畫出現(xiàn)的時(shí)候，就意味著一個(gè)信息，那就是沒(méi)有任何信息，我們不知道它要持續(xù)多久，不知道它什么時(shí)候結(jié)束，加載時(shí)間太久我們甚至不知道它是還沒(méi)加載完還是已經(jīng)“死掉了”，也做不了任何操作，除了等待，我們沒(méi)有任何辦法。

雖然我們很希望在訪問(wèn)端發(fā)送請(qǐng)求時(shí)，能馬上得到所有信息，但是因?yàn)榉?wù)器的處理、響應(yīng)、訪問(wèn)端的渲染，包括物理端的存儲(chǔ)（下載）等，都需要時(shí)間，為了讓這個(gè)時(shí)間可視化，所以出現(xiàn)了進(jìn)度條，那為什么還會(huì)出現(xiàn) Loading 這個(gè)設(shè)計(jì)？為什么不把所有的 loading 都換成進(jìn)度條呢？

1）懶得做

因?yàn)樽鲞M(jìn)度條是需要計(jì)算總進(jìn)度以及已完成和未完成進(jìn)度來(lái)繪制出可視化的進(jìn)度條圖形，包括百分比和剩余時(shí)間，也都需要進(jìn)行計(jì)算，相比直接顯示 Loading 動(dòng)畫來(lái)說(shuō)，開發(fā)量更大，有時(shí)候并不一定都是開發(fā)人員懶得做，而是企業(yè)或產(chǎn)品經(jīng)理基于時(shí)間和成本考慮，以犧牲用戶體驗(yàn)為代價(jià)，用 Loading 來(lái)取代進(jìn)度條的設(shè)計(jì)。

2）效益低

這種就是在一些特定的場(chǎng)景下選擇放棄進(jìn)度條而改用 Loading 的設(shè)計(jì)，比如在上傳圖片時(shí)，系統(tǒng)限制了最大只能上傳2M的圖片，在5G的網(wǎng)速下這樣的一張圖片一瞬間就上傳完了，這樣的情況下，用戶可能還沒(méi)看到進(jìn)度條出現(xiàn)就已經(jīng)看到上傳成功的提示，那這個(gè)進(jìn)度條就沒(méi)什么意義了，相反，有時(shí)候?yàn)榱顺尸F(xiàn)完整的進(jìn)度條動(dòng)畫，圖片已經(jīng)上傳完了，進(jìn)度條動(dòng)畫還沒(méi)播放完，對(duì)用戶來(lái)講，體驗(yàn)就更加糟糕了。

3）難以量化

假如我有10個(gè)蘋果，吃了一個(gè)，你可以說(shuō)我吃掉了10%，但如果我咬了一口，問(wèn)你我吃了多少，這個(gè)是很難準(zhǔn)確回答的。同理，大文件的上傳下載可以通過(guò)文件大小和網(wǎng)速來(lái)計(jì)算時(shí)間以及百分比，但是如果是查詢、讀取文本數(shù)據(jù)的時(shí)候，則較難量化。

雖然 Loading 是被迫妥協(xié)的設(shè)計(jì)，但每天為了用戶體驗(yàn)“殫精竭慮”的產(chǎn)品經(jīng)理們還是盡可能地讓它變得更加友好，我們可以看看 Loading 的幾個(gè)發(fā)展階段。

1、Loading 動(dòng)畫出現(xiàn)時(shí)，整個(gè)頁(yè)面出現(xiàn)遮罩，什么都做不了，加載超時(shí) Loading 動(dòng)畫也不會(huì)消失，只能刷新頁(yè)面。

2、頁(yè)面分區(qū)域加載，只在對(duì)應(yīng)加載區(qū)域出現(xiàn) Loading 動(dòng)畫，加載時(shí)不影響其他區(qū)域的操作。

3、在上一階段的基礎(chǔ)上，給 Loading 加一個(gè)延遲出現(xiàn)的時(shí)間，比如2秒，如果數(shù)據(jù)在2秒內(nèi)就加載完成則不會(huì)出現(xiàn) Loading 動(dòng)畫；設(shè)置加載超時(shí)時(shí)間，比如加載了10秒鐘還沒(méi)有出來(lái)，可能已經(jīng)加載失敗，則停止加載和 Loading 動(dòng)畫，允許用戶手動(dòng)點(diǎn)擊重新加載。

什么情況下用進(jìn)度條？什么情況下用 Loading？等待時(shí)間較長(zhǎng)，但數(shù)據(jù)可量化的情況下，用進(jìn)度條，比如上傳、下載等；等待時(shí)間較短，或處理數(shù)據(jù)體量較小，或較難量化的情況下，用Loading，如提交、查詢數(shù)據(jù)等。

四、并發(fā)

有時(shí)候我們?cè)谶M(jìn)行一些操作，比如點(diǎn)擊一些按鈕時(shí)，會(huì)發(fā)現(xiàn)它有一個(gè)處理的過(guò)程，在處理完成之前，不允許我們多次點(diǎn)擊，如下圖。

還有發(fā)送短信驗(yàn)證碼的按鈕，等待時(shí)間更長(zhǎng)，要我們等60秒。

我們有這樣一種體驗(yàn)，當(dāng)我們?cè)陲埖瓿燥埖臅r(shí)候，如果上菜時(shí)間太久，我們一般會(huì)讓服務(wù)員去后廚催一下廚師。

我們可以設(shè)想一下這種場(chǎng)景，我們剛讓一個(gè)服務(wù)員去催菜，這個(gè)服務(wù)員還沒(méi)走到后廚，我們又讓另外一個(gè)服務(wù)員去催，同樣，第二個(gè)服務(wù)員還沒(méi)走到后廚，我們又讓第三個(gè)服務(wù)員去催，接下來(lái)廚師就會(huì)連續(xù)收到3個(gè)服務(wù)員的催菜要求，你想想，這個(gè)廚師會(huì)怎樣。

或者我們?cè)O(shè)想另外一種場(chǎng)景，我們讓服務(wù)員去催菜，這個(gè)時(shí)候，另外兩桌的客人也同時(shí)找了服務(wù)員去催菜，我們假設(shè)，如果這3個(gè)服務(wù)員剛好催的是同一個(gè)廚師，你可以想想，這個(gè)廚師會(huì)怎樣。

上面所講的例子，在技術(shù)中，叫做——“并發(fā)”。第一種場(chǎng)景是同一個(gè)用戶短時(shí)間內(nèi)重復(fù)發(fā)送相同的請(qǐng)求；第二種場(chǎng)景是多個(gè)用戶同一時(shí)間發(fā)送相同的請(qǐng)求。

第一種場(chǎng)景中，可能是因?yàn)橛脩袅?xí)慣性雙擊按鈕，或者系統(tǒng)反應(yīng)不夠及時(shí)，讓用戶以為系統(tǒng)假死，用戶會(huì)習(xí)慣性多次點(diǎn)擊，或者系統(tǒng)遭遇病毒或網(wǎng)絡(luò)爬蟲的暴力請(qǐng)求，在這種情況下，系統(tǒng)會(huì)在短時(shí)間內(nèi)收到多次相同的請(qǐng)求，這個(gè)時(shí)候系統(tǒng)往往還沒(méi)有處理完前面的請(qǐng)求，就要介入處理新的請(qǐng)求，如果短時(shí)間內(nèi)請(qǐng)求達(dá)到一定數(shù)量，可能會(huì)直接導(dǎo)致系統(tǒng)卡死。

針對(duì)這種場(chǎng)景的并發(fā)，一般處理方式有兩種。

1）前端優(yōu)化

功能觸發(fā)后，在處理完成前禁止再次點(diǎn)擊。這種就好比你剛找服務(wù)員催菜，沒(méi)隔多久又找服務(wù)員催，服務(wù)員就告訴你，剛催過(guò)了，耐心等待。

2）后端策略

短時(shí)間內(nèi)的多次點(diǎn)擊只處理一次，比如在1秒內(nèi)連續(xù)點(diǎn)擊一個(gè)按鈕，系統(tǒng)只當(dāng)作是點(diǎn)擊了一次處理。這種就好比你剛找服務(wù)員催菜，沒(méi)隔多久又找服務(wù)員催，服務(wù)員說(shuō)了一句好的就走開了，但是其實(shí)他沒(méi)有幫你去催。

以上兩種方式，條件允許的情況下前后端都應(yīng)該同步做，比如上文提到的短信驗(yàn)證碼，有時(shí)候我們點(diǎn)擊發(fā)送按鈕出現(xiàn)倒計(jì)時(shí)之后，刷新頁(yè)面會(huì)發(fā)現(xiàn)發(fā)送按鈕又可以點(diǎn)擊了，但再次點(diǎn)擊時(shí)，系統(tǒng)又提示發(fā)送驗(yàn)證碼太頻繁之類的，這就是前后端共同作用的效果，至于為什么要讓用戶等待60秒這么長(zhǎng)的時(shí)間，除了基于系統(tǒng)性能原因考慮之外，另一個(gè)原因就是成本，假如平臺(tái)用戶量大，如果用戶每點(diǎn)擊一次就發(fā)送一條短信，那么每個(gè)用戶無(wú)意間點(diǎn)多幾下，平臺(tái)可能就要支付巨額的短信費(fèi)用。

第二種場(chǎng)景常見于秒殺，或者像過(guò)年大家都在平臺(tái)上搶紅包之類的，大量的用戶涌入到平臺(tái)，幾乎同一時(shí)間都在發(fā)送相同的請(qǐng)求，這種場(chǎng)景考驗(yàn)的就不只是系統(tǒng)的穩(wěn)定性，更考驗(yàn)服務(wù)器的性能，我們有時(shí)候會(huì)聽到研發(fā)說(shuō)每秒多少并發(fā)，指的就是系統(tǒng)最多能夠處理多少個(gè)人同時(shí)發(fā)送的請(qǐng)求。

要處理這種場(chǎng)景的并發(fā)，首要是提升服務(wù)器的性能，支持更多并發(fā)數(shù)，這就是我們經(jīng)常看到一些大平臺(tái)，在大型節(jié)假日做活動(dòng)之前，有時(shí)候會(huì)公告說(shuō)在升級(jí)服務(wù)器、提升服務(wù)器性能之類的，這些手段都是為了服務(wù)器接下來(lái)在活動(dòng)期間能夠更好地迎接流量沖擊。當(dāng)然，服務(wù)器升級(jí)擴(kuò)容等是有成本的，一定要根據(jù)平臺(tái)的實(shí)際情況來(lái)確定，如果平臺(tái)的最高并發(fā)數(shù)是10萬(wàn)，你把服務(wù)器性能提升到可承受100萬(wàn)并發(fā)數(shù)，那就大可不必。

另一方面，系統(tǒng)上也需要在一些容易產(chǎn)生高并發(fā)的操作中加入優(yōu)化策略，比如我們有時(shí)候會(huì)遇到，在秒殺的時(shí)候，系統(tǒng)提示正在排隊(duì)，其實(shí)是系統(tǒng)延遲向服務(wù)器發(fā)送你的請(qǐng)求，把你的請(qǐng)求放在一個(gè)隊(duì)列中，按順序發(fā)送請(qǐng)求，這樣在一定程度上可以有效防止服務(wù)器因?yàn)橐凰查g收到太多請(qǐng)求而承受不住。

以上便是本文的全部?jī)?nèi)容，感謝閱讀！