“一提到秒殺很簡(jiǎn)單這個(gè)話題，我知道要被別人鄙視了：你不懂高并發(fā)... 這年頭開(kāi)頭不畫(huà)個(gè)思維導(dǎo)圖都覺(jué)得掉價(jià)

談到秒殺，網(wǎng)絡(luò)上不少于幾千片文章，但是大多大同小異。如果你的微信當(dāng)中關(guān)注了幾個(gè)編程技術(shù)類(lèi)的公眾號(hào)，我敢說(shuō)，每個(gè)公眾號(hào)幾乎都發(fā)過(guò)秒殺的文章

秒殺這種場(chǎng)景在流量這個(gè)維度很有獨(dú)特性，大起大落的流量沖擊對(duì)系統(tǒng)是個(gè)考驗(yàn)。為什么這么說(shuō)呢？大的流量或者說(shuō)高并發(fā)請(qǐng)求，考驗(yàn)的不僅僅是數(shù)據(jù)庫(kù)的最大承受壓力，而且對(duì)于帶寬也有很大的考驗(yàn)，入口流量之后就是對(duì)整個(gè)系統(tǒng)的承受能力的考驗(yàn)。

其實(shí)我覺(jué)得這里大多數(shù)人有一個(gè)誤解：秒殺對(duì)整個(gè)系統(tǒng)的考驗(yàn)，最終會(huì)落到數(shù)據(jù)庫(kù)上。正是這個(gè)誤解，導(dǎo)致了大多數(shù)人會(huì)對(duì)DB優(yōu)化花費(fèi)很大的精力。

現(xiàn)實(shí)的世界存在矛盾，只要找到矛盾就能解決問(wèn)題，對(duì)應(yīng)到編程也一樣。

秒殺之所以被神化，是因?yàn)榱髁看螅呛芏嘞到y(tǒng)最后崩塌的卻是數(shù)據(jù)庫(kù)，很少有團(tuán)隊(duì)因?yàn)閼?yīng)用系統(tǒng)崩潰而導(dǎo)致秒殺失敗。因?yàn)閷?duì)于整個(gè)系統(tǒng)來(lái)說(shuō)，數(shù)據(jù)庫(kù)是數(shù)據(jù)最后的持久化，是存在狀態(tài)的，而應(yīng)用系統(tǒng)一般都是無(wú)狀態(tài)的，都是可以橫向擴(kuò)展的。

其實(shí)說(shuō)到底，流量還是要削峰或者分流，我想如果把流量削到數(shù)據(jù)庫(kù)的可承受范圍之內(nèi)，秒殺可能和其他業(yè)務(wù)場(chǎng)景無(wú)異。

過(guò)多的中間件

說(shuō)出來(lái)你們肯定見(jiàn)過(guò)，網(wǎng)絡(luò)一大堆秒殺的解決方案，又是XXMQ，又是XX緩存，又是XX負(fù)載均衡，又是XX中間件。雖然架構(gòu)圖很完美，但是落地呢？

落地是有難度的，而且還有很大風(fēng)險(xiǎn)。難道各種中間件不用維護(hù)嗎？中間件不會(huì)出故障嗎？每個(gè)中間件不用做高可用嗎？這么多中間件搭配起來(lái)，運(yùn)維成本是很高的，最主要的是出問(wèn)題排查問(wèn)題的成本會(huì)很高。

我們需要的是架構(gòu)師，不是框架師。把復(fù)雜問(wèn)題用簡(jiǎn)單的解決方案解決，才不會(huì)給自己挖坑，我一直是這么認(rèn)為。

那中間件需要嗎？肯定是需要的，那么多成熟的東西真的能解決你很多問(wèn)題，但是前提是正確的用。比如Redis，做緩存用途很正確，但是你把它當(dāng)做高速數(shù)據(jù)庫(kù)我就不認(rèn)同了，雖然它可以持久化，但是大并發(fā)的情況下，Redis做數(shù)據(jù)庫(kù)是不合適的。

吃掉所有流量

秒殺業(yè)務(wù)具體能到多大流量誰(shuí)也不能確定，雖然可以根據(jù)以往經(jīng)驗(yàn)預(yù)估，但是往往還是會(huì)超出想象。要想把這些流量全部流入服務(wù)器進(jìn)行處理，需要付出很多資源。最壞的情況是，把流量全部吃掉之后，還要吐出90%，這就讓人惱火了。

所以，能不能只吃能夠吃飽的流量呢？比如說(shuō)：庫(kù)存有1000件商品，如果我們只放進(jìn)來(lái)1000個(gè)請(qǐng)求（雖然很牽強(qiáng)），那整個(gè)系統(tǒng)是不是很容易構(gòu)建。就像吃飯一樣：本來(lái)一碗米飯就能吃飽，非要吃下10碗，然后吐出9碗嗎？

SO，是不是只要在系統(tǒng)邊緣加一個(gè)限流就ok了？值得思考

客戶端UI

無(wú)論業(yè)務(wù)怎么樣，客戶端用戶體驗(yàn)總要給人一種還有希望的感覺(jué)。

其實(shí)秒殺這種場(chǎng)景是最能發(fā)揮忽悠人才能的了，你前面有多少人排隊(duì)，天王老子也別想知道。就算真的要給用戶反饋前面還有多少人，其實(shí)完全可以返回一個(gè)不太離譜的隨機(jī)數(shù)，反正用戶又不會(huì)電話投訴。

多說(shuō)一句，甚至把限流算法放到客戶端都行，反正不懂行的又看不懂代碼，這種騷操作我確實(shí)見(jiàn)過(guò)。

如果非要返回真實(shí)的排隊(duì)人數(shù)的話，可以引入一個(gè)線程安全的中心化隊(duì)列即可，比如用神器Redis，每成功穿過(guò)限流窗口一個(gè)請(qǐng)求，就把對(duì)應(yīng)的UserId插入這個(gè)隊(duì)列，這個(gè)隊(duì)列理論上不會(huì)太大，因?yàn)橛谐绦蛞恢痹谙M(fèi)。

靜態(tài)資源

所謂的靜態(tài)資源就是指那些不會(huì)變動(dòng)或者很少變動(dòng)的資源，比如商品的圖片就屬于這種。在秒殺這種場(chǎng)景下，靜態(tài)資源的訪問(wèn)一定要分離出業(yè)務(wù)服務(wù)器，最好的解決方案是利用CDN來(lái)加速。

CDN是個(gè)好東西，誰(shuí)用誰(shuí)知道。不但可以降低自己服務(wù)器的壓力，而且還可以給全國(guó)各地的用戶請(qǐng)求加速，具體原理咱們之后有機(jī)會(huì)可以嘮嘮。如果技術(shù)允許的情況下，甚至一些邊緣計(jì)算的能力都可以放置在CDN。

寫(xiě)在最后

如果不是阿里，騰訊這種量級(jí)的公司，一般中小公司搞秒殺活動(dòng)并不是想象中那么恐怖。大家可以放平心態(tài)。做技術(shù)一定不要亂了陣腳，技術(shù)的選擇固然重要，但是更重要的是有全局掌控的能力，哪個(gè)環(huán)節(jié)最容易出問(wèn)題，要做好全面監(jiān)控，出了問(wèn)題第一時(shí)間能解決問(wèn)題才是后期最重要的。