Go語(yǔ)言中怎么實(shí)現(xiàn)每分鐘處理100萬(wàn)個(gè)請(qǐng)求

今天就跟大家聊聊有關(guān)Go語(yǔ)言中怎么實(shí)現(xiàn)每分鐘處理100萬(wàn)個(gè)請(qǐng)求，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)公司是專業(yè)的武義網(wǎng)站建設(shè)公司，武義接單;提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行武義網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛(ài)的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!

Go語(yǔ)言程序的單純方法

最初我們采取了一個(gè)非常單純的POST處理方式，僅僅試圖將任務(wù)并行化處理放到一個(gè)簡(jiǎn)單的goroutine：

對(duì)于中等負(fù)載來(lái)說(shuō)，這可能對(duì)大多數(shù)人是有效的，但這很快證明在大型負(fù)載時(shí)，效果不太好。我們預(yù)期有很多的請(qǐng)求，但當(dāng)我們部署第一個(gè)版本到產(chǎn)品中時(shí)，并沒(méi)有看到這個(gè)數(shù)量級(jí)的請(qǐng)求。我們完全低估了流量。

上面的方法在幾個(gè)方面都不好，沒(méi)有辦法控制我們正在大量生產(chǎn)的Go程序要產(chǎn)生多少個(gè)例程。由于我們每分鐘收到100萬(wàn)個(gè)POST請(qǐng)求，理所當(dāng)然的，這段代碼很快就崩潰了。

再次嘗試

我們需要尋找一個(gè)不同的方式。從一開(kāi)始，我們就討論如何保持請(qǐng)求處理程序的生命周期非常短，并在后臺(tái)生成處理進(jìn)程。當(dāng)然，這是必須在Ruby on Rails領(lǐng)域要做的，否則這將限制所有可用的web處理器，無(wú)論你使用的是puma, unicorn, passenger中的哪一個(gè)（請(qǐng)不要參加JRuby討論）。那么我們就需要利用通用的解決方案去做這個(gè)，例如Resque, Sidekiq, SQS,等等。清單還可以繼續(xù)列下去，因?yàn)橛泻芏喾椒梢宰龅竭@一點(diǎn)。

所以第二個(gè)版本是創(chuàng)建一個(gè)緩存通道，在這里我們可以對(duì)一些作業(yè)進(jìn)行排隊(duì)并上傳到S3，由于我們可以控制隊(duì)列中的最大項(xiàng)目數(shù)，在內(nèi)存中我們有足夠多的RAM對(duì)任務(wù)進(jìn)行排隊(duì)，我們認(rèn)為只在通道隊(duì)列中緩存作業(yè)是可以的。

然后實(shí)際上的作業(yè)出列和處理，我們使用的是類似的函數(shù)：

說(shuō)實(shí)話，我不知道我們?cè)谙胧裁?。這一定是一個(gè)充滿紅牛的深夜。這種方法沒(méi)有給我們帶來(lái)任何好處，我們用緩沖隊(duì)列來(lái)交換有缺陷的并發(fā)，也只是推遲了問(wèn)題的產(chǎn)生時(shí)間而已。我們的同步處理器一次只上傳一個(gè)有效負(fù)載到S3,而且由于傳入請(qǐng)求的速率比單處理器上傳到S3的能力大得多，所以緩沖通道很快就達(dá)到了極限，限制了請(qǐng)求處理程序來(lái)排隊(duì)更多項(xiàng)目的能力。

我們只是簡(jiǎn)單地回避這個(gè)問(wèn)題，最終導(dǎo)致系統(tǒng)的死亡。在我們部署了這個(gè)有缺陷的版本之后，我們的延遲率以不變的速率持續(xù)增長(zhǎng)。

更好的解決方案

當(dāng)使用Go語(yǔ)言通道時(shí)，我們決定利用通用模式以便創(chuàng)造一個(gè)2階的通道系統(tǒng)，一個(gè)用于作業(yè)排隊(duì)，另外一個(gè)控制多少作業(yè)者同時(shí)在JobQueue上操作。

這個(gè)想法是以某種可持續(xù)的速度并行上傳到S3，它既不會(huì)削弱機(jī)器性能，也不會(huì)從S3開(kāi)始生成連接錯(cuò)誤。所以我們選擇了創(chuàng)建一個(gè)作業(yè)/作業(yè)者模式。對(duì)那些熟悉java,C#等語(yǔ)言的人來(lái)說(shuō)，可以考慮采用Go語(yǔ)言實(shí)現(xiàn)通道方式而不是作業(yè)者線程池的方式。

我們修改了Web請(qǐng)求處理程序，創(chuàng)建一個(gè)帶負(fù)載的jobstruct實(shí)例，發(fā)送到JobQueue通道，便于作業(yè)者去拾取。

在網(wǎng)站服務(wù)器初始化過(guò)程中，我們創(chuàng)建一個(gè)Dispatcher，調(diào)用Run()去創(chuàng)建一個(gè)作業(yè)者池，開(kāi)始偵聽(tīng)出現(xiàn)在JobQueue的作業(yè)。

dispatcher := NewDispatcher(MaxWorker)

dispatcher.Run()

下面是用于dispatcher執(zhí)行的代碼：

注意，我們會(huì)提供被實(shí)例化和被添加到作業(yè)者池的最大的作業(yè)者量。 因?yàn)槲覀冞@個(gè)帶有dockerized Go環(huán)境的項(xiàng)目使用了亞馬遜Elasticbeanstalk，我們總是設(shè)法遵循12要素方法論來(lái)配置生產(chǎn)中的系統(tǒng)，從環(huán)境變量中讀取這些數(shù)值。這樣就可以控制有多少作業(yè)者和作業(yè)隊(duì)列的最大值，因此，我們可以快速地調(diào)整這些值，而不需要重新部署集群。

var (

MaxWorker = os.Getenv(“MAX_WORKERS”)

MaxQueue = os.Getenv(“MAX_QUEUE”)

)

在部署完它之后，我們立刻發(fā)現(xiàn)所有的延遲率都降到了無(wú)關(guān)緊要的數(shù)字，系統(tǒng)處理請(qǐng)求的能力急劇上升。

彈性負(fù)載均衡完全預(yù)熱幾分鐘后，我們看到ElasticBeanstalk應(yīng)用服務(wù)每分鐘逼近100萬(wàn)個(gè)請(qǐng)求。通常在早晨的幾個(gè)小時(shí)里，流量高峰會(huì)超過(guò)每分鐘100萬(wàn)個(gè)請(qǐng)求。

一旦我們部署了新的代碼，服務(wù)器的數(shù)量從100臺(tái)減少到大約20臺(tái)。

在恰當(dāng)?shù)嘏渲昧思汉妥詣?dòng)縮放設(shè)置以后，我們能夠把它降低到僅有4x EC2 c4。如果CPU連續(xù)5分鐘超過(guò)90%，大型實(shí)例和彈性自動(dòng)縮放設(shè)置就生成一個(gè)新實(shí)例。

看完上述內(nèi)容，你們對(duì)Go語(yǔ)言中怎么實(shí)現(xiàn)每分鐘處理100萬(wàn)個(gè)請(qǐng)求有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

本文名稱：Go語(yǔ)言中怎么實(shí)現(xiàn)每分鐘處理100萬(wàn)個(gè)請(qǐng)求
地址分享：http://bm7419.com/article26/jdspcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、域名注冊(cè)、小程序開(kāi)發(fā)、響應(yīng)式網(wǎng)站、全網(wǎng)營(yíng)銷推廣、手機(jī)網(wǎng)站建設(shè)

廣告

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