當(dāng)Golang遇到高并發(fā)秒殺怎么辦

這篇文章給大家分享的是有關(guān)當(dāng)Golang遇到高并發(fā)秒殺怎么辦的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考。一起跟隨小編過來看看吧。

遇到GO語言也是偶爾的一次機(jī)會，工作上做架構(gòu)相關(guān)的事情，對新發(fā)展比較火爆的語言肯定要關(guān)注下。就這樣步入了GO語言的世界，GO給我?guī)砹巳碌捏w驗(yàn);

　　一直做一件事情的人往往會被一件事情所困，開始實(shí)踐GO語言的時(shí)候總感覺哪哪都別扭，特別是把結(jié)構(gòu)體當(dāng)成類，還有結(jié)構(gòu)體的繼承，寫面向?qū)ο攵嗔碎_始還真扭不過來。不過寫的多了漸漸地也習(xí)慣了，甚至感覺越來越順眼。

　　在熟悉了GO一段時(shí)間后，也停止了一會，腦子里一直在想著GO的簡潔(代碼風(fēng)格一致，用起來簡練不拖泥帶水，部署極其簡單，編譯速度用快來形容)，能給項(xiàng)目系統(tǒng)和架構(gòu)帶來哪些改變。但是當(dāng)時(shí)一時(shí)半會兒還真沒想到有多大幫助，后來系統(tǒng)逐步開始用GO實(shí)現(xiàn)，用的多了慢慢地發(fā)現(xiàn)：

　　咦～，部署再也不要搭建依賴環(huán)境了(不部署環(huán)境發(fā)布，剛開始還真有點(diǎn)不習(xí)慣，總感覺少來點(diǎn)什么;

　　別人寫的代碼看著也沒有抵觸心理，雖然說有的代碼不是自己寫的，仔細(xì)閱讀的時(shí)候就感覺像是自己寫的，寫JAVA 和PHP的時(shí)候 閱讀代碼哪是從內(nèi)心拒絕的;

　　開發(fā)某個(gè)微服務(wù)接口一切變得簡單了，寫個(gè)main，寫個(gè)接口，提交，秒秒種就上線了～;

　　上面主要說了自己和GO的相遇還有GO給我?guī)淼某醪接绊懀驮谀程焱砩衔夷X袋里突然蹦出一個(gè)想法，GO語言用簡潔帶來諸多提升，從事的架構(gòu)系統(tǒng)是否也能利用GO來簡化，降低系統(tǒng)復(fù)雜度?這個(gè)想法從蹦出來，就一直在我腦袋里徘徊?；叵雱傞_始從事架構(gòu)相關(guān)事情的時(shí)候，一看到講中間件有什么原理，有什么優(yōu)化能提高性能就非常興奮，埋頭苦研直到自己感覺掌握(當(dāng)然現(xiàn)在也要)，然后就信誓旦旦的用到系統(tǒng)中，感覺系統(tǒng)架構(gòu)用中間件組件越多越好，越多越顯得自己做的架構(gòu)有多厲害。但是隨著越做越久你就會發(fā)現(xiàn)，系統(tǒng)能用就行，不能為了架構(gòu)而架構(gòu)。從傳統(tǒng)技術(shù)棧上做減法同樣需要深厚的功底，因?yàn)橹挥谐浞种兰夹g(shù)原理才能替換，也才敢想敢干，不出問題。常言道：“條條大陸通羅馬”，從個(gè)人較角度講架構(gòu)要適合當(dāng)時(shí)的業(yè)務(wù)，達(dá)到用盡可能少的代價(jià)完成盡可能多的事情就算達(dá)到架構(gòu)設(shè)計(jì)的目標(biāo)了，就比如消耗服務(wù)器資源相同情況下能支撐好幾倍甚至好幾十倍的請求，達(dá)到相同請求量的情況下，實(shí)現(xiàn)和部署非常簡單可操作等。GO的思想這段時(shí)間就一直這么潛移默化地影響這我。

　　直到我們公司決定做微服務(wù)，剛開始我們用java做微服務(wù)。后來想了下其它語言是否也能做微服務(wù)，自然而然的就想到了GO，經(jīng)過一番折騰后感覺還可以，就用GO開始寫點(diǎn)微服務(wù)，寫著寫著就發(fā)現(xiàn)Golang 寫微服務(wù)還挺順手，效率那個(gè)高啊，也不用封裝tomcat(這東西放jar包里，感覺特別不合適)，二進(jìn)制不用系統(tǒng)依賴都能在docker里面跑(不信你試試)，就這樣打心底來說越來越喜歡GO，后續(xù)的系統(tǒng)啥的也想用GO重構(gòu)(寫多了java多了遇到這么方便的真是感覺發(fā)現(xiàn)了春天)GO已經(jīng)深入的影響了對系統(tǒng)的架構(gòu)的看法。

　　但究竟什么是架構(gòu)，架構(gòu)師又是這么煉成的 ?在這里分享下架構(gòu)師煉成的八段艱辛：

　　第一段：搬磚分為能辦好磚和只會搬磚(有一批人留在了搬磚上，剩下的繼續(xù)發(fā)展);

　　第二段：能搬磚的可以分為要了解原理的和編程就是搬磚的;

　　第三段：了解原理的又分為不斷研究的和一知半解的;

　　第四段：不斷研究也能分成兩種研究深入有廣度和蜻蜓點(diǎn)水沒廣度的;

　　第五段：有深度有廣度的又分為純技術(shù)型和業(yè)務(wù)型(開始分化);

　　第六段：業(yè)務(wù)型要求有良好溝通，對系統(tǒng)和需求有一定設(shè)計(jì)把控能力的;

　　第七段：這層很容易出現(xiàn)單純使用堆中間件搭出“架構(gòu)”系統(tǒng)的(初級架構(gòu)師);

　　第八段：這層很重要的一點(diǎn)，考慮問題足夠細(xì)致、全面、善于溝通。做底層實(shí)現(xiàn)，理解底層原理，從業(yè)務(wù)，研發(fā)，測試，部署，維護(hù)升級多角度出發(fā)，因地制宜搭出的“架構(gòu)”是為了開發(fā)效率，為了運(yùn)行效率，為了開發(fā)質(zhì)量，為了業(yè)務(wù)靈活和運(yùn)行穩(wěn)定，為了維護(hù)方便等等這樣的人，可稱為架構(gòu)師(有這方面經(jīng)驗(yàn)的回想下，有多少架構(gòu)是表面上看著漂亮，實(shí)際用著難受的)。

　　在做秒殺系統(tǒng)的時(shí)候，剛開始想到也最容易想到的傳統(tǒng)技術(shù)棧就是，分布式session，Redis集群，分布式緩存，nginx反向代理nginx深層優(yōu)化，機(jī)器優(yōu)化，消息隊(duì)列。沒錯Cap老師當(dāng)年也是想到這些，也認(rèn)為這些“成熟”的技術(shù)能應(yīng)用到我們秒殺系統(tǒng)中沒問題，況且公司內(nèi)部討論都感覺這些沒問題。而且做了深入的研究比如：

　　1.分布式Session 我們化了很大的力氣，用Nginx+web+redis集群的方式來保存Session達(dá)到Session驗(yàn)證的目的，單點(diǎn)Session這塊的架構(gòu)就如下圖所示：

　　乍一看沒問題，都是這么做的，真的大流量來了，就加Nginx，web服務(wù)器，也滿足橫向擴(kuò)展，但是流量達(dá)到上億級別以后我門的成本有點(diǎn)大，來回的網(wǎng)絡(luò)請求session的時(shí)間我們也想壓榨(那時(shí)候總感覺哪里不對)，nginx在高流量下也時(shí)不時(shí)出現(xiàn)504。

　　2.分布式緩存，這東西看著很簡單，但是在大流量高并發(fā)系統(tǒng)里面是個(gè)非常復(fù)雜的事情，主要能遇到以下一些問題;

　　1)緩存一致性(如果用這個(gè)的話，處理不好會出現(xiàn)超賣);

　　2)緩存穿透;

　　3)緩存雪崩;

　　4)緩存黑洞問題：

　　5)狗樁效應(yīng);

　　.....還有許多需要注意的事情，總之分布式緩存用途很廣泛也很有價(jià)值，但是要建立一個(gè)能夠滿足高并發(fā)，大流量的分布式緩存系統(tǒng)需要極強(qiáng)的技術(shù)團(tuán)隊(duì)支持，實(shí)現(xiàn)起來也特別的復(fù)雜這里就不在贅述;

　　然而，我們看似沒有問題的解決方案存在巨大的問題，實(shí)現(xiàn)“太不容易了”，門檻那個(gè)是高啊。用起來資源成本也是蠻高的，Session要滿足橫向擴(kuò)展，web緩存也要滿足橫向擴(kuò)展，包括redis集群也要滿足，只能是不斷的加集群;

　　舉個(gè)簡單的例子(拋去其它因素，為了說明架構(gòu)的重要性)，假設(shè)我們現(xiàn)在單臺機(jī)器，接口有5000QPS的處理能力(8核8G)，要處理秒殺的上億流量，秒殺開始瞬時(shí)流量按照300W預(yù)估，平均等待按照時(shí)間7秒計(jì)算(接口容忍到3.5WQPS)，得出的結(jié)果也就是我們系統(tǒng)，就接口這塊需要將近90臺，這還沒有算其它同等要求的的配套服務(wù)器，這些配套服務(wù)器簡單說明如下;

　　1.首先nginx層面要有同等級處理能力(每臺不優(yōu)化大概2WQPS，預(yù)估20臺左右);

　　2.web接口同樣要擴(kuò)展到相應(yīng)等級(預(yù)估的90臺);

　　3.Reids集群多商品有情況下有左右(單獨(dú)商品，大量訪問量的情況下集群也沒用);

　　上面是分布式Session要滿足的機(jī)器需求，還沒算上分布式緩存，同學(xué)們大概可以感覺到做個(gè)和做好秒殺系統(tǒng)有多么不容易了，部署的復(fù)雜度也還沒考慮。實(shí)施起來真是復(fù)雜，經(jīng)驗(yàn)4-5年一兩個(gè)人短時(shí)間還真完成不了。能想出其它的辦法來簡化嗎?答案是：有的。首先要理解原理，其次要從架構(gòu)上做減法。不用就沒有必要優(yōu)化。

　　要從哪些地方優(yōu)化呢?

　　1)Session在秒殺并發(fā)里，根據(jù)權(quán)限驗(yàn)證的原理是可以省略的;

　　2)我們可以不用分布式緩存(用接口代替);

　　3)把nginx也省了(降低運(yùn)維難度);

　　4)redis集群也可以省略;

　　這么一除二去，秒殺怎么做啊?用java和php不是不能實(shí)現(xiàn)，而是實(shí)現(xiàn)起來可以比較吃力，但是現(xiàn)在可以結(jié)合GO語言特性來給我們提供新的思路;

　　1.Nginx 可以省略，直接用GO啟動端口暴露服務(wù)(這里可以省去nginx);

　　2.采用cookie方式或者wt方式來代替分布式Session方案，服務(wù)器端代碼層面驗(yàn)證;

　　3.超賣采用接口形式代替redis集群;

　　4.負(fù)載均衡采用廉價(jià)的SLB(避免了Nginx);

　　秒殺優(yōu)化以后總統(tǒng)架構(gòu)可以展示為下圖結(jié)構(gòu)，詳細(xì)做法請參閱《Go高并發(fā)秒殺實(shí)踐》：

　　從改造后的結(jié)果來看我們主要列下：

　　1.web應(yīng)用都采用Go部署進(jìn)制文件的方法，centos服務(wù)器不需要按照任何依賴(極大的方便了部署)：

　　2.采用SLB廉價(jià)實(shí)用方案避免了nginx的反向代理，甚至高級lua腳本也避免了;

　　3.redis集群在這里也被避免了，采用接口的方式提供服務(wù);

　　整個(gè)技術(shù)棧只需要會：GO，RabbitMQ，Mysql就能完成高并發(fā)秒殺系統(tǒng)，首先從易操作上就很誘人;下面大家可以在調(diào)整后的架構(gòu)上推演下(目前單機(jī)GO提供web接口，在未經(jīng)過優(yōu)化的情況下大概能達(dá)到2WQPS)：

　　1.單機(jī)GO接口權(quán)限驗(yàn)證性能提高4倍，部署復(fù)雜度可以說已經(jīng)接近與零(無nginx，無redis集群，運(yùn)行也無依賴環(huán)境);

　　2.隨著流量等級的不斷提高只需要添加web服務(wù)器和數(shù)量控制服務(wù)器，沒有其它服務(wù)開銷(擴(kuò)展性上可以說是盡最大的可能降低了成本，成正比例增長模式，且無性能瓶頸);

　　3.對比傳統(tǒng)方案，服務(wù)器數(shù)量降低不止4倍(大家可以在原有的基礎(chǔ)上計(jì)算下);

　　上面的解決方案是在GO語言的簡單的基礎(chǔ)上實(shí)現(xiàn)的，恰巧GO部署方便提高了易實(shí)現(xiàn)性，有恰好GO能提供web服務(wù)減少了外部依賴(本身web務(wù)性能也很高)。有了GO的兩個(gè)恰到好處的特性，在配合架構(gòu)上減法操作，讓秒殺系統(tǒng)整體實(shí)現(xiàn)不在是件難事，當(dāng)然java和PHP都可以做上圖中調(diào)整后的秒殺架構(gòu)，但是從多方面考慮來講，總統(tǒng)還是GO優(yōu)勢明顯點(diǎn)。

　　回首看方案感覺是Go帶動了思維模式的改變，本身簡單帶動了實(shí)現(xiàn)簡單，本身高效穩(wěn)定帶動了架構(gòu)優(yōu)化。好的系統(tǒng)架構(gòu)就應(yīng)該簡單，高效，易實(shí)現(xiàn);

感謝各位的閱讀！關(guān)于當(dāng)Golang遇到高并發(fā)秒殺怎么辦就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！