【另類見解】秒殺并非高不可攀
時間:2021-09-16 14:17:49
手機看文章
掃描二維碼
隨時隨地手機看文章
[導(dǎo)讀]“一提到秒殺很簡單這個話題,我知道要被別人鄙視了:你不懂高并發(fā)這年頭開頭不畫個思維導(dǎo)圖都覺得掉價image談到秒殺,網(wǎng)絡(luò)上不少于幾千片文章,但是大多大同小異。如果你的微信當(dāng)中關(guān)注了幾個編程技術(shù)類的公眾號,我敢說,每個公眾號幾乎都發(fā)過秒殺的文章秒殺這種場景在流量這個維度很有獨特性,...
“一提到秒殺很簡單這個話題,我知道要被別人鄙視了:你不懂高并發(fā)... 這年頭開頭不畫個思維導(dǎo)圖都覺得掉價

大起大落的流量
沖擊對系統(tǒng)是個考驗。為什么這么說呢?大的流量或者說高并發(fā)請求,考驗的不僅僅是數(shù)據(jù)庫的最大承受壓力,而且對于帶寬
也有很大的考驗,入口流量之后就是對整個系統(tǒng)的承受能力的考驗。其實我覺得這里大多數(shù)人有一個誤解:秒殺對整個系統(tǒng)的考驗,最終會落到數(shù)據(jù)庫上。正是這個誤解,導(dǎo)致了大多數(shù)人會對DB優(yōu)化花費很大的精力。現(xiàn)實的世界存在矛盾,只要找到矛盾就能解決問題,對應(yīng)到編程也一樣。秒殺之所以被神化,是因為流量大,但是很多系統(tǒng)最后崩塌的卻是數(shù)據(jù)庫
,很少有團隊因為應(yīng)用系統(tǒng)崩潰而導(dǎo)致秒殺失敗。因為對于整個系統(tǒng)來說,數(shù)據(jù)庫是數(shù)據(jù)最后的持久化,是存在狀態(tài)的,而應(yīng)用系統(tǒng)一般都是無狀態(tài)的,都是可以橫向擴展的。其實說到底,流量還是要削峰或者分流
,我想如果把流量削到數(shù)據(jù)庫的可承受范圍之內(nèi),秒殺可能和其他業(yè)務(wù)場景無異。過多的中間件
說出來你們肯定見過,網(wǎng)絡(luò)一大堆秒殺的解決方案,又是XXMQ,又是XX緩存,又是XX負載均衡,又是XX中間件。雖然架構(gòu)圖很完美,但是落地呢?落地是有難度的,而且還有很大風(fēng)險。難道各種中間件不用維護嗎?中間件不會出故障嗎?每個中間件不用做高可用嗎?這么多中間件搭配起來,運維成本是很高的,最主要的是出問題排查問題的成本會很高。我們需要的是架構(gòu)師,不是框架師。把復(fù)雜問題用簡單的解決方案解決,才不會給自己挖坑,我一直是這么認為。那中間件需要嗎?肯定是需要的,那么多成熟的東西真的能解決你很多問題,但是前提是正確的用。比如Redis,做緩存用途很正確,但是你把它當(dāng)做高速數(shù)據(jù)庫我就不認同了,雖然它可以持久化,但是大并發(fā)的情況下,Redis做數(shù)據(jù)庫是不合適的。吃掉所有流量
秒殺業(yè)務(wù)具體能到多大流量誰也不能確定,雖然可以根據(jù)以往經(jīng)驗預(yù)估,但是往往還是會超出想象。要想把這些流量全部流入服務(wù)器進行處理,需要付出很多資源。最壞的情況是,把流量全部吃掉之后,還要吐出90%,這就讓人惱火了。所以,能不能只吃能夠吃飽
的流量呢?比如說:庫存有1000件商品,如果我們只放進來1000個請求(雖然很牽強),那整個系統(tǒng)是不是很容易構(gòu)建。就像吃飯一樣:本來一碗米飯就能吃飽,非要吃下10碗,然后吐出9碗嗎?SO,是不是只要在系統(tǒng)邊緣加一個限流就
ok了?值得思考
客戶端UI
無論業(yè)務(wù)怎么樣,客戶端用戶體驗總要給人一種還有希望的感覺
。
發(fā)揮忽悠人才能的了
,你前面有多少人排隊,天王老子也別想知道。就算真的要給用戶反饋前面還有多少人,其實完全可以返回一個不太離譜的隨機數(shù),反正用戶又不會電話投訴。多說一句,甚至把限流算法放到客戶端都行,反正不懂行的又看不懂代碼,這種騷操作我確實見過。如果非要返回真實的排隊人數(shù)的話,可以引入一個線程安全的中心化隊列即可
,比如用神器Redis,每成功穿過限流窗口一個請求,就把對應(yīng)的UserId插入這個隊列,這個隊列理論上不會太大,因為有程序一直在消費。
靜態(tài)資源
所謂的靜態(tài)資源就是指那些不會變動或者很少變動的資源,比如商品的圖片就屬于這種。在秒殺這種場景下,靜態(tài)資源的訪問一定要分離出業(yè)務(wù)服務(wù)器,最好的解決方案是利用CDN來加速
。CDN是個好東西,誰用誰知道。不但可以降低自己服務(wù)器的壓力,而且還可以給全國各地的用戶請求加速,具體原理咱們之后有機會可以嘮嘮。如果技術(shù)允許的情況下,甚至一些邊緣計算的能力都可以放置在CDN。