共計 1855 個字符，預計需要花費 5 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
今天就跟大家聊聊有關 Go 語言中怎么實現每分鐘處理 100 萬個請求，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
Go 語言程序的單純方法
最初我們采取了一個非常單純的 POST 處理方式，僅僅試圖將任務并行化處理放到一個簡單的 goroutine：
對于中等負載來說，這可能對大多數人是有效的，但這很快證明在大型負載時，效果不太好。我們預期有很多的請求，但當我們部署第一個版本到產品中時，并沒有看到這個數量級的請求。我們完全低估了流量。
上面的方法在幾個方面都不好，沒有辦法控制我們正在大量生產的 Go 程序要產生多少個例程。由于我們每分鐘收到 100 萬個 POST 請求，理所當然的，這段代碼很快就崩潰了。
再次嘗試
我們需要尋找一個不同的方式。從一開始，我們就討論如何保持請求處理程序的生命周期非常短，并在后臺生成處理進程。當然，這是必須在 Ruby on Rails 領域要做的，否則這將限制所有可用的 web 處理器，無論你使用的是 puma, unicorn, passenger 中的哪一個（請不要參加 JRuby 討論）。那么我們就需要利用通用的解決方案去做這個，例如 Resque, Sidekiq, SQS, 等等。清單還可以繼續列下去，因為有很多方法可以做到這一點。
所以第二個版本是創建一個緩存通道，在這里我們可以對一些作業進行排隊并上傳到 S3，由于我們可以控制隊列中的最大項目數，在內存中我們有足夠多的 RAM 對任務進行排隊，我們認為只在通道隊列中緩存作業是可以的。
然后實際上的作業出列和處理，我們使用的是類似的函數：
說實話，我不知道我們在想什么。這一定是一個充滿紅牛的深夜。這種方法沒有給我們帶來任何好處，我們用緩沖隊列來交換有缺陷的并發，也只是推遲了問題的產生時間而已。我們的同步處理器一次只上傳一個有效負載到 S3, 而且由于傳入請求的速率比單處理器上傳到 S3 的能力大得多，所以緩沖通道很快就達到了極限，限制了請求處理程序來排隊更多項目的能力。
我們只是簡單地回避這個問題，最終導致系統的死亡。在我們部署了這個有缺陷的版本之后，我們的延遲率以不變的速率持續增長。
更好的解決方案
當使用 Go 語言通道時，我們決定利用通用模式以便創造一個 2 階的通道系統，一個用于作業排隊，另外一個控制多少作業者同時在 JobQueue 上操作。
這個想法是以某種可持續的速度并行上傳到 S3，它既不會削弱機器性能，也不會從 S3 開始生成連接錯誤。所以我們選擇了創建一個作業 / 作業者模式。對那些熟悉 java,C# 等語言的人來說，可以考慮采用 Go 語言實現通道方式而不是作業者線程池的方式。
我們修改了 Web 請求處理程序，創建一個帶負載的 jobstruct 實例，發送到 JobQueue 通道，便于作業者去拾取。
在網站服務器初始化過程中，我們創建一個 Dispatcher，調用 Run() 去創建一個作業者池，開始偵聽出現在 JobQueue 的作業。
dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()
下面是用于 dispatcher 執行的代碼：
注意，我們會提供被實例化和被添加到作業者池的最大的作業者量。因為我們這個帶有 dockerized Go 環境的項目使用了亞馬遜 Elasticbeanstalk，我們總是設法遵循 12 要素方法論來配置生產中的系統，從環境變量中讀取這些數值。這樣就可以控制有多少作業者和作業隊列的最大值，因此，我們可以快速地調整這些值，而不需要重新部署集群。
var (
MaxWorker = os.Getenv(“MAX_WORKERS”)
MaxQueue = os.Getenv(“MAX_QUEUE”)
)
在部署完它之后，我們立刻發現所有的延遲率都降到了無關緊要的數字，系統處理請求的能力急劇上升。
彈性負載均衡完全預熱幾分鐘后，我們看到 ElasticBeanstalk 應用服務每分鐘逼近 100 萬個請求。通常在早晨的幾個小時里，流量高峰會超過每分鐘 100 萬個請求。
一旦我們部署了新的代碼，服務器的數量從 100 臺減少到大約 20 臺。
在恰當地配置了集群和自動縮放設置以后，我們能夠把它降低到僅有 4x EC2 c4。如果 CPU 連續 5 分鐘超過 90%，大型實例和彈性自動縮放設置就生成一個新實例。
看完上述內容，你們對 Go 語言中怎么實現每分鐘處理 100 萬個請求有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
向 AI 問一下細節
