當(dāng)Golang遇到高并發(fā)秒殺怎么辦-創(chuàng)新互聯(lián)

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

在吉木薩爾等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需網(wǎng)站開發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站制作,吉木薩爾網(wǎng)站建設(shè)費用合理。

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

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

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

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

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

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

上面主要說了自己和GO的相遇還有GO給我?guī)淼某醪接绊?，就在某天晚上我腦袋里突然蹦出一個想法，GO語言用簡潔帶來諸多提升，從事的架構(gòu)系統(tǒng)是否也能利用GO來簡化，降低系統(tǒng)復(fù)雜度?這個想法從蹦出來，就一直在我腦袋里徘徊?；叵雱傞_始從事架構(gòu)相關(guān)事情的時候，一看到講中間件有什么原理，有什么優(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ù)棧上做減法同樣需要深厚的功底，因為只有充分知道技術(shù)原理才能替換，也才敢想敢干，不出問題。常言道：“條條大陸通羅馬”，從個人較角度講架構(gòu)要適合當(dāng)時的業(yè)務(wù)，達(dá)到用盡可能少的代價完成盡可能多的事情就算達(dá)到架構(gòu)設(shè)計的目標(biāo)了，就比如消耗服務(wù)器資源相同情況下能支撐好幾倍甚至好幾十倍的請求，達(dá)到相同請求量的情況下，實現(xiàn)和部署非常簡單可操作等。GO的思想這段時間就一直這么潛移默化地影響這我。

直到我們公司決定做微服務(wù)，剛開始我們用java做微服務(wù)。后來想了下其它語言是否也能做微服務(wù)，自然而然的就想到了GO，經(jīng)過一番折騰后感覺還可以，就用GO開始寫點微服務(wù)，寫著寫著就發(fā)現(xiàn)Golang 寫微服務(wù)還挺順手，效率那個高啊，也不用封裝tomcat(這東西放jar包里，感覺特別不合適)，二進制不用系統(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ā)展);

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

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

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

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

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

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

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

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

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

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

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

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

2)緩存穿透;

3)緩存雪崩;

4)緩存黑洞問題：

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

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

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

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

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

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

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

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

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

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

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

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

4)redis集群也可以省略;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新聞名稱：當(dāng)Golang遇到高并發(fā)秒殺怎么辦-創(chuàng)新互聯(lián)
當(dāng)前網(wǎng)址：http://muchs.cn/article18/dphpgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計公司、電子商務(wù)、App設(shè)計、微信公眾號、品牌網(wǎng)站建設(shè)、手機網(wǎng)站建設(shè)

廣告

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