go語(yǔ)言并發(fā)方法 go語(yǔ)言并發(fā)編程實(shí)戰(zhàn)

《Go語(yǔ)言并發(fā)之道》pdf下載在線閱讀全文，求百度網(wǎng)盤云資源

《Go語(yǔ)言并發(fā)之道》百度網(wǎng)盤pdf最新全集下載:

創(chuàng)新互聯(lián)公司主營(yíng)新干網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,app軟件定制開發(fā),新干h5微信小程序定制開發(fā)搭建,新干網(wǎng)站營(yíng)銷推廣歡迎新干等地區(qū)企業(yè)咨詢

鏈接：

?pwd=v91m 提取碼：v91m

簡(jiǎn)介：本書作者帶你一步一步深入這些方法。你將理解 Go語(yǔ)言為何選定這些并發(fā)模型，這些模型又會(huì)帶來(lái)什么問(wèn)題，

以及你如何組合利用這些模型中的原語(yǔ)去解決問(wèn)題。學(xué)習(xí)那些讓你在獨(dú)立且自信的編寫與實(shí)現(xiàn)任何規(guī)模并發(fā)系統(tǒng)時(shí)所需要用到的技巧和工具。 ?

GO語(yǔ)言商業(yè)案例（十八）：stream

切換到新語(yǔ)言始終是一大步，尤其是當(dāng)您的團(tuán)隊(duì)成員只有一個(gè)時(shí)有該語(yǔ)言的先前經(jīng)驗(yàn)?，F(xiàn)在，Stream 的主要編程語(yǔ)言從 Python 切換到了 Go。這篇文章將解釋stream決定放棄 Python 并轉(zhuǎn)向 Go 的一些原因。

Go 非常快。性能類似于 Java 或 C++。對(duì)于用例，Go 通常比 Python 快 40 倍。

對(duì)于許多應(yīng)用程序來(lái)說(shuō)，編程語(yǔ)言只是應(yīng)用程序和數(shù)據(jù)庫(kù)之間的粘合劑。語(yǔ)言本身的性能通常并不重要。然而，Stream 是一個(gè)API 提供商，為 700 家公司和超過(guò) 5 億最終用戶提供提要和聊天平臺(tái)。多年來(lái)，我們一直在優(yōu)化 Cassandra、PostgreSQL、Redis 等，但最終，您會(huì)達(dá)到所使用語(yǔ)言的極限。Python 是一門很棒的語(yǔ)言，但對(duì)于序列化/反序列化、排名和聚合等用例，它的性能相當(dāng)緩慢。我們經(jīng)常遇到性能問(wèn)題，Cassandra 需要 1 毫秒來(lái)檢索數(shù)據(jù)，而 Python 會(huì)花費(fèi)接下來(lái)的 10 毫秒將其轉(zhuǎn)換為對(duì)象。

看看我如何開始 Go 教程中的一小段 Go 代碼。（這是一個(gè)很棒的教程，也是學(xué)習(xí) Go 的一個(gè)很好的起點(diǎn)。）

如果您是 Go 新手，那么在閱讀那個(gè)小代碼片段時(shí)不會(huì)有太多讓您感到驚訝的事情。它展示了多個(gè)賦值、數(shù)據(jù)結(jié)構(gòu)、指針、格式和一個(gè)內(nèi)置的 HTTP 庫(kù)。當(dāng)我第一次開始編程時(shí)，我一直喜歡使用 Python 更高級(jí)的功能。Python 允許您在編寫代碼時(shí)獲得相當(dāng)?shù)膭?chuàng)意。例如，您可以：

這些功能玩起來(lái)很有趣，但是，正如大多數(shù)程序員會(huì)同意的那樣，在閱讀別人的作品時(shí)，它們通常會(huì)使代碼更難理解。Go 迫使你堅(jiān)持基礎(chǔ)。這使得閱讀任何人的代碼并立即了解發(fā)生了什么變得非常容易。 注意：當(dāng)然，它實(shí)際上有多“容易”取決于您的用例。如果你想創(chuàng)建一個(gè)基本的 CRUD API，我仍然推薦 Django + DRF或 Rails。

作為一門語(yǔ)言，Go 試圖讓事情變得簡(jiǎn)單。它沒(méi)有引入許多新概念。重點(diǎn)是創(chuàng)建一種非?？焖偾乙子谑褂玫暮?jiǎn)單語(yǔ)言。它唯一具有創(chuàng)新性的領(lǐng)域是 goroutine 和通道。（100% 正確CSP的概念始于 1977 年，所以這項(xiàng)創(chuàng)新更多是對(duì)舊思想的一種新方法。）Goroutines 是 Go 的輕量級(jí)線程方法，通道是 goroutines 之間通信的首選方式。Goroutines 的創(chuàng)建非常便宜，并且只需要幾 KB 的額外內(nèi)存。因?yàn)?Goroutine 非常輕量，所以有可能同時(shí)運(yùn)行數(shù)百甚至數(shù)千個(gè)。您可以使用通道在 goroutine 之間進(jìn)行通信。Go 運(yùn)行時(shí)處理所有復(fù)雜性。goroutines 和基于通道的并發(fā)方法使得使用所有可用的 CPU 內(nèi)核和處理并發(fā) IO 變得非常容易——所有這些都不會(huì)使開發(fā)復(fù)雜化。與 Python/Java 相比，在 goroutine 上運(yùn)行函數(shù)需要最少的樣板代碼。您只需在函數(shù)調(diào)用前加上關(guān)鍵字“go”：

Go 的并發(fā)方法很容易使用。與 Node 相比，這是一種有趣的方法，開發(fā)人員必須密切關(guān)注異步代碼的處理方式。Go 中并發(fā)的另一個(gè)重要方面是競(jìng)爭(zhēng)檢測(cè)器。這樣可以很容易地確定異步代碼中是否存在任何競(jìng)爭(zhēng)條件。

我們目前用 Go 編寫的最大的微服務(wù)編譯需要 4 秒。與以編譯速度慢而聞名的 Java 和 C++ 等語(yǔ)言相比，Go 的快速編譯時(shí)間是一項(xiàng)重大的生產(chǎn)力勝利。我喜歡在程序編譯的時(shí)候摸魚，但在我還記得代碼應(yīng)該做什么的同時(shí)完成事情會(huì)更好。

首先，讓我們從顯而易見(jiàn)的開始：與 C++ 和 Java 等舊語(yǔ)言相比，Go 開發(fā)人員的數(shù)量并不多。根據(jù)StackOverflow的數(shù)據(jù)， 38% 的開發(fā)人員知道 Java， 19.3% 的人知道 C++，只有 4.6% 的人知道 Go。GitHub 數(shù)據(jù)顯示了類似的趨勢(shì)：Go 比 Erlang、Scala 和 Elixir 等語(yǔ)言使用更廣泛，但不如 Java 和 C++ 流行。幸運(yùn)的是，Go 是一種非常簡(jiǎn)單易學(xué)的語(yǔ)言。它提供了您需要的基本功能，僅此而已。它引入的新概念是“延遲”聲明和內(nèi)置的并發(fā)管理與“goroutines”和通道。（對(duì)于純粹主義者來(lái)說(shuō)：Go 并不是第一種實(shí)現(xiàn)這些概念的語(yǔ)言，只是第一種使它們流行起來(lái)的語(yǔ)言。）任何加入團(tuán)隊(duì)的 Python、Elixir、C++、Scala 或 Java 開發(fā)人員都可以在一個(gè)月內(nèi)在 Go 上發(fā)揮作用，因?yàn)樗暮?jiǎn)單性。與許多其他語(yǔ)言相比，我們發(fā)現(xiàn)組建 Go 開發(fā)人員團(tuán)隊(duì)更容易。如果您在博爾德和阿姆斯特丹等競(jìng)爭(zhēng)激烈的生態(tài)系統(tǒng)中招聘人員，這是一項(xiàng)重要的優(yōu)勢(shì)。

對(duì)于我們這樣規(guī)模的團(tuán)隊(duì)（約 20 人）來(lái)說(shuō)，生態(tài)系統(tǒng)很重要。如果您必須重新發(fā)明每一個(gè)小功能，您根本無(wú)法為您的客戶創(chuàng)造價(jià)值。Go 對(duì)我們使用的工具有很好的支持。實(shí)體庫(kù)已經(jīng)可用于 Redis、RabbitMQ、PostgreSQL、模板解析、任務(wù)調(diào)度、表達(dá)式解析和 RocksDB。與 Rust 或 Elixir 等其他較新的語(yǔ)言相比，Go 的生態(tài)系統(tǒng)是一個(gè)重大勝利。它當(dāng)然不如 Java、Python 或 Node 之類的語(yǔ)言好，但它很可靠，而且對(duì)于許多基本需求，你會(huì)發(fā)現(xiàn)已經(jīng)有高質(zhì)量的包可用。

Gofmt 是一個(gè)很棒的命令行實(shí)用程序，內(nèi)置在 Go 編譯器中，用于格式化代碼。就功能而言，它與 Python 的 autopep8 非常相似。我們大多數(shù)人并不真正喜歡爭(zhēng)論制表符與空格。格式的一致性很重要，但實(shí)際的格式標(biāo)準(zhǔn)并不那么重要。Gofmt 通過(guò)使用一種正式的方式來(lái)格式化您的代碼來(lái)避免所有這些討論。

Go 對(duì)協(xié)議緩沖區(qū)和 gRPC 具有一流的支持。這兩個(gè)工具非常適合構(gòu)建需要通過(guò) RPC 通信的微服務(wù)。您只需要編寫一個(gè)清單，在其中定義可以進(jìn)行的 RPC 調(diào)用以及它們采用的參數(shù)。然后從這個(gè)清單中自動(dòng)生成服務(wù)器和客戶端代碼。生成的代碼既快速又具有非常小的網(wǎng)絡(luò)占用空間并且易于使用。從同一個(gè)清單中，您甚至可以為許多不同的語(yǔ)言生成客戶端代碼，例如 C++、Java、Python 和 Ruby。因此，內(nèi)部流量不再有模棱兩可的 REST 端點(diǎn)，您每次都必須編寫幾乎相同的客戶端和服務(wù)器代碼。.

Go 沒(méi)有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那樣的單一主導(dǎo)框架。這是 Go 社區(qū)內(nèi)激烈爭(zhēng)論的話題，因?yàn)樵S多人主張你不應(yīng)該一開始就使用框架。我完全同意這對(duì)于某些用例是正確的。但是，如果有人想構(gòu)建一個(gè)簡(jiǎn)單的 CRUD API，他們將更容易使用 Django/DJRF、Rails Laravel 或Phoenix。對(duì)于 Stream 的用例，我們更喜歡不使用框架。然而，對(duì)于許多希望提供簡(jiǎn)單 CRUD API 的新項(xiàng)目來(lái)說(shuō)，缺乏主導(dǎo)框架將是一個(gè)嚴(yán)重的劣勢(shì)。

Go 通過(guò)簡(jiǎn)單地從函數(shù)返回錯(cuò)誤并期望調(diào)用代碼來(lái)處理錯(cuò)誤（或?qū)⑵浞祷氐秸{(diào)用堆棧）來(lái)處理錯(cuò)誤。雖然這種方法有效，但很容易失去問(wèn)題的范圍，以確保您可以向用戶提供有意義的錯(cuò)誤。錯(cuò)誤包通過(guò)允許您向錯(cuò)誤添加上下文和堆棧跟蹤來(lái)解決此問(wèn)題。另一個(gè)問(wèn)題是很容易忘記處理錯(cuò)誤。像 errcheck 和 megacheck 這樣的靜態(tài)分析工具可以方便地避免犯這些錯(cuò)誤。雖然這些變通辦法效果很好，但感覺(jué)不太對(duì)勁。您希望該語(yǔ)言支持正確的錯(cuò)誤處理。

Go 的包管理絕不是完美的。默認(rèn)情況下，它無(wú)法指定特定版本的依賴項(xiàng)，也無(wú)法創(chuàng)建可重現(xiàn)的構(gòu)建。Python、Node 和 Ruby 都有更好的包管理系統(tǒng)。但是，使用正確的工具，Go 的包管理工作得很好。您可以使用Dep來(lái)管理您的依賴項(xiàng)，以允許指定和固定版本。除此之外，我們還貢獻(xiàn)了一個(gè)名為的開源工具VirtualGo，它可以更輕松地處理用 Go 編寫的多個(gè)項(xiàng)目。

我們進(jìn)行的一個(gè)有趣的實(shí)驗(yàn)是在 Python 中使用我們的排名提要功能并在 Go 中重寫它?？纯催@個(gè)排名方法的例子：

Python 和 Go 代碼都需要執(zhí)行以下操作來(lái)支持這種排名方法：

開發(fā) Python 版本的排名代碼大約花了 3 天時(shí)間。這包括編寫代碼、單元測(cè)試和文檔。接下來(lái)，我們花了大約 2 周的時(shí)間優(yōu)化代碼。其中一項(xiàng)優(yōu)化是將分?jǐn)?shù)表達(dá)式 (simple_gauss(time)*popularity) 轉(zhuǎn)換為抽象語(yǔ)法樹. 我們還實(shí)現(xiàn)了緩存邏輯，可以在未來(lái)的特定時(shí)間預(yù)先計(jì)算分?jǐn)?shù)。相比之下，開發(fā)此代碼的 Go 版本大約需要 4 天時(shí)間。性能不需要任何進(jìn)一步的優(yōu)化。因此，雖然 Python 的最初開發(fā)速度更快，但基于 Go 的版本最終需要我們團(tuán)隊(duì)的工作量大大減少。另外一個(gè)好處是，Go 代碼的執(zhí)行速度比我們高度優(yōu)化的 Python 代碼快大約 40 倍?，F(xiàn)在，這只是我們通過(guò)切換到 Go 體驗(yàn)到的性能提升的一個(gè)示例。

與 Python 相比，我們系統(tǒng)的其他一些組件在 Go 中構(gòu)建所需的時(shí)間要多得多。作為一個(gè)總體趨勢(shì)，我們看到 開發(fā) Go 代碼需要更多的努力。但是，我們花更少的時(shí)間 優(yōu)化 代碼以提高性能。

我們?cè)u(píng)估的另一種語(yǔ)言是Elixir.。Elixir 建立在 Erlang 虛擬機(jī)之上。這是一種迷人的語(yǔ)言，我們之所以考慮它，是因?yàn)槲覀兊囊幻麍F(tuán)隊(duì)成員在 Erlang 方面擁有豐富的經(jīng)驗(yàn)。對(duì)于我們的用例，我們注意到 Go 的原始性能要好得多。Go 和 Elixir 都可以很好地服務(wù)數(shù)千個(gè)并發(fā)請(qǐng)求。但是，如果您查看單個(gè)請(qǐng)求的性能，Go 對(duì)于我們的用例來(lái)說(shuō)要快得多。我們選擇 Go 而不是 Elixir 的另一個(gè)原因是生態(tài)系統(tǒng)。對(duì)于我們需要的組件，Go 有更成熟的庫(kù)，而在許多情況下，Elixir 庫(kù)還沒(méi)有準(zhǔn)備好用于生產(chǎn)環(huán)境。培訓(xùn)/尋找開發(fā)人員使用 Elixir 也更加困難。這些原因使天平向 Go 傾斜。Elixir 的 Phoenix 框架看起來(lái)很棒，絕對(duì)值得一看。

Go 是一種非常高性能的語(yǔ)言，對(duì)并發(fā)有很好的支持。它幾乎與 C++ 和 Java 等語(yǔ)言一樣快。雖然與 Python 或 Ruby 相比，使用 Go 構(gòu)建東西確實(shí)需要更多時(shí)間，但您將節(jié)省大量用于優(yōu)化代碼的時(shí)間。我們?cè)赟tream有一個(gè)小型開發(fā)團(tuán)隊(duì)，為超過(guò) 5 億最終用戶提供動(dòng)力和聊天。Go 結(jié)合了 強(qiáng)大的生態(tài)系統(tǒng) 、新開發(fā)人員的 輕松入門、快速的性能 、對(duì)并發(fā)的 可靠支持和高效的編程環(huán)境 ，使其成為一個(gè)不錯(cuò)的選擇。Stream 仍然在我們的儀表板、站點(diǎn)和機(jī)器學(xué)習(xí)中利用 Python 來(lái)提供個(gè)性化的訂閱源. 我們不會(huì)很快與 Python 說(shuō)再見(jiàn)，但今后所有性能密集型代碼都將使用 Go 編寫。我們新的聊天 API也完全用 Go 編寫。

如何用go語(yǔ)言每分鐘處理100萬(wàn)個(gè)請(qǐng)求

在Malwarebytes 我們經(jīng)歷了顯著的增長(zhǎng)，自從我一年前加入了硅谷的公司，一個(gè)主要的職責(zé)成了設(shè)計(jì)架構(gòu)和開發(fā)一些系統(tǒng)來(lái)支持一個(gè)快速增長(zhǎng)的信息安全公司和所有需要的設(shè)施來(lái)支持一個(gè)每天百萬(wàn)用戶使用的產(chǎn)品。我在反病毒和反惡意軟件行業(yè)的不同公司工作了12年，從而我知道由于我們每天處理大量的數(shù)據(jù)，這些系統(tǒng)是多么復(fù)雜。

有趣的是，在過(guò)去的大約9年間，我參與的所有的web后端的開發(fā)通常是通過(guò)Ruby on Rails技術(shù)實(shí)現(xiàn)的。不要錯(cuò)怪我。我喜歡Ruby on Rails，并且我相信它是個(gè)令人驚訝的環(huán)境。但是一段時(shí)間后，你會(huì)開始以ruby的方式開始思考和設(shè)計(jì)系統(tǒng)，你會(huì)忘記，如果你可以利用多線程、并行、快速執(zhí)行和小內(nèi)存開銷，軟件架構(gòu)本來(lái)應(yīng)該是多么高效和簡(jiǎn)單。很多年期間，我是一個(gè)c/c++、Delphi和c#開發(fā)者，我剛開始意識(shí)到使用正確的工具可以把復(fù)雜的事情變得簡(jiǎn)單些。

作為首席架構(gòu)師，我不會(huì)很關(guān)心在互聯(lián)網(wǎng)上的語(yǔ)言和框架戰(zhàn)爭(zhēng)。我相信效率、生產(chǎn)力。代碼可維護(hù)性主要依賴于你如何把解決方案設(shè)計(jì)得很簡(jiǎn)單。

問(wèn)題

當(dāng)工作在我們的匿名遙測(cè)和分析系統(tǒng)中，我們的目標(biāo)是可以處理來(lái)自于百萬(wàn)級(jí)別的終端的大量的POST請(qǐng)求。web處理服務(wù)可以接收包含了很多payload的集合的JSON數(shù)據(jù)，這些數(shù)據(jù)需要寫入Amazon S3中。接下來(lái)，map-reduce系統(tǒng)可以操作這些數(shù)據(jù)。

按照習(xí)慣，我們會(huì)調(diào)研服務(wù)層級(jí)架構(gòu)，涉及的軟件如下：

Sidekiq

Resque

DelayedJob

Elasticbeanstalk Worker Tier

RabbitMQ

and so on…

搭建了2個(gè)不同的集群，一個(gè)提供web前端，另外一個(gè)提供后端處理，這樣我們可以橫向擴(kuò)展后端服務(wù)的數(shù)量。

但是，從剛開始，在 討論階段我們的團(tuán)隊(duì)就知道我們應(yīng)該使用Go，因?yàn)槲覀兛吹竭@會(huì)潛在性地成為一個(gè)非常龐大（ large traffic）的系統(tǒng)。我已經(jīng)使用了Go語(yǔ)言大約2年時(shí)間，我們開發(fā)了幾個(gè)系統(tǒng)，但是很少會(huì)達(dá)到這樣的負(fù)載（amount of load）。

我們開始創(chuàng)建一些結(jié)構(gòu)，定義從POST調(diào)用得到的web請(qǐng)求負(fù)載，還有一個(gè)上傳到S3 budket的函數(shù)。

type PayloadCollection struct {

WindowsVersion string `json:"version"`

Token string `json:"token"`

Payloads []Payload `json:"data"`

}

type Payload struct {

// [redacted]

}

func (p *Payload) UploadToS3() error {

// the storageFolder method ensures that there are no name collision in

// case we get same timestamp in the key name

storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())

bucket := S3Bucket

b := new(bytes.Buffer)

encodeErr := json.NewEncoder(b).Encode(payload)

if encodeErr != nil {

return encodeErr

}

// Everything we post to the S3 bucket should be marked 'private'

var acl = s3.Private

var contentType = "application/octet-stream"

return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})

}

本地Go routines方法

剛開始，我們采用了一個(gè)非常本地化的POST處理實(shí)現(xiàn)，僅僅嘗試把發(fā)到簡(jiǎn)單go routine的job并行化：

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

go payload.UploadToS3() // ----- DON'T DO THIS

}

w.WriteHeader(http.StatusOK)

}

對(duì)于中小負(fù)載，這會(huì)對(duì)大多數(shù)的人適用，但是大規(guī)模下，這個(gè)方案會(huì)很快被證明不是很好用。我們期望的請(qǐng)求數(shù)，不在我們剛開始計(jì)劃的數(shù)量級(jí)，當(dāng)我們把第一個(gè)版本部署到生產(chǎn)環(huán)境上。我們完全低估了流量。

上面的方案在很多地方很不好。沒(méi)有辦法控制我們產(chǎn)生的go routine的數(shù)量。由于我們收到了每分鐘1百萬(wàn)的POST請(qǐng)求，這段代碼很快就崩潰了。

再次嘗試

我們需要找一個(gè)不同的方式。自開始我們就討論過(guò)， 我們需要保持請(qǐng)求處理程序的生命周期很短，并且進(jìn)程在后臺(tái)產(chǎn)生。當(dāng)然，這是你在Ruby on Rails的世界里必須要做的事情，否則你會(huì)阻塞在所有可用的工作 web處理器上，不管你是使用puma、unicore還是passenger（我們不要討論JRuby這個(gè)話題）。然后我們需要利用常用的處理方案來(lái)做這些，比如Resque、 Sidekiq、 SQS等。這個(gè)列表會(huì)繼續(xù)保留，因?yàn)橛泻芏嗟姆桨缚梢詫?shí)現(xiàn)這些。

所以，第二次迭代，我們創(chuàng)建了一個(gè)緩沖channel，我們可以把job排隊(duì)，然后把它們上傳到S3。因?yàn)槲覀兛梢钥刂莆覀冴?duì)列中的item最大值，我們有大量的內(nèi)存來(lái)排列job，我們認(rèn)為只要把job在channel里面緩沖就可以了。

var Queue chan Payload

func init() {

Queue = make(chan Payload, MAX_QUEUE)

}

func payloadHandler(w http.ResponseWriter, r *http.Request) {

...

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

Queue - payload

}

...

}

接下來(lái)，我們?cè)購(gòu)年?duì)列中取job，然后處理它們。我們使用類似于下面的代碼：

func StartProcessor() {

for {

select {

case job := -Queue:

job.payload.UploadToS3() // -- STILL NOT GOOD

}

}

}

說(shuō)實(shí)話，我不知道我們?cè)谙胧裁?。這肯定是一個(gè)滿是Red-Bulls的夜晚。這個(gè)方法不會(huì)帶來(lái)什么改善，我們用了一個(gè) 有缺陷的緩沖隊(duì)列并發(fā)，僅僅是把問(wèn)題推遲了。我們的同步處理器同時(shí)僅僅會(huì)上傳一個(gè)數(shù)據(jù)到S3，因?yàn)閬?lái)到的請(qǐng)求遠(yuǎn)遠(yuǎn)大于單核處理器上傳到S3的能力，我們的帶緩沖channel很快達(dá)到了它的極限，然后阻塞了請(qǐng)求處理邏輯的queue更多item的能力。

我們僅僅避免了問(wèn)題，同時(shí)開始了我們的系統(tǒng)掛掉的倒計(jì)時(shí)。當(dāng)部署了這個(gè)有缺陷的版本后，我們的延時(shí)保持在每分鐘以常量增長(zhǎng)。

最好的解決方案

我們討論過(guò)在使用用Go channel時(shí)利用一種常用的模式，來(lái)創(chuàng)建一個(gè)二級(jí)channel系統(tǒng)，一個(gè)來(lái)queue job，另外一個(gè)來(lái)控制使用多少個(gè)worker來(lái)并發(fā)操作JobQueue。

想法是，以一個(gè)恒定速率并行上傳到S3，既不會(huì)導(dǎo)致機(jī)器崩潰也不好產(chǎn)生S3的連接錯(cuò)誤。這樣我們選擇了創(chuàng)建一個(gè)Job/Worker模式。對(duì)于那些熟悉Java、C#等語(yǔ)言的開發(fā)者，可以把這種模式想象成利用channel以golang的方式來(lái)實(shí)現(xiàn)了一個(gè)worker線程池，作為一種替代。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

// Job represents the job to be run

type Job struct {

Payload Payload

}

// A buffered channel that we can send work requests on.

var JobQueue chan Job

// Worker represents the worker that executes the job

type Worker struct {

WorkerPool chan chan Job

JobChannel chan Job

quit chan bool

}

func NewWorker(workerPool chan chan Job) Worker {

return Worker{

WorkerPool: workerPool,

JobChannel: make(chan Job),

quit: make(chan bool)}

}

// Start method starts the run loop for the worker, listening for a quit channel in

// case we need to stop it

func (w Worker) Start() {

go func() {

for {

// register the current worker into the worker queue.

w.WorkerPool - w.JobChannel

select {

case job := -w.JobChannel:

// we have received a work request.

if err := job.Payload.UploadToS3(); err != nil {

log.Errorf("Error uploading to S3: %s", err.Error())

}

case -w.quit:

// we have received a signal to stop

return

}

}

}()

}

// Stop signals the worker to stop listening for work requests.

func (w Worker) Stop() {

go func() {

w.quit - true

}()

}

我們已經(jīng)修改了我們的web請(qǐng)求handler，用payload創(chuàng)建一個(gè)Job實(shí)例，然后發(fā)到JobQueue channel，以便于worker來(lái)獲取。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

// let's create a job with the payload

work := Job{Payload: payload}

// Push the work onto the queue.

JobQueue - work

}

w.WriteHeader(http.StatusOK)

}

在web server初始化時(shí)，我們創(chuàng)建一個(gè)Dispatcher，然后調(diào)用Run()函數(shù)創(chuàng)建一個(gè)worker池子，然后開始監(jiān)聽(tīng)JobQueue中的job。

dispatcher := NewDispatcher(MaxWorker)

dispatcher.Run()

下面是dispatcher的實(shí)現(xiàn)代碼：

type Dispatcher struct {

// A pool of workers channels that are registered with the dispatcher

WorkerPool chan chan Job

}

func NewDispatcher(maxWorkers int) *Dispatcher {

pool := make(chan chan Job, maxWorkers)

return Dispatcher{WorkerPool: pool}

}

func (d *Dispatcher) Run() {

// starting n number of workers

for i := 0; i d.maxWorkers; i++ {

worker := NewWorker(d.pool)

worker.Start()

}

go d.dispatch()

}

func (d *Dispatcher) dispatch() {

for {

select {

case job := -JobQueue:

// a job request has been received

go func(job Job) {

// try to obtain a worker job channel that is available.

// this will block until a worker is idle

jobChannel := -d.WorkerPool

// dispatch the job to the worker job channel

jobChannel - job

}(job)

}

}

}

注意到，我們提供了初始化并加入到池子的worker的最大數(shù)量。因?yàn)檫@個(gè)工程我們利用了Amazon Elasticbeanstalk帶有的docker化的Go環(huán)境，所以我們常常會(huì)遵守12-factor方法論來(lái)配置我們的生成環(huán)境中的系統(tǒng)，我們從環(huán)境變了讀取這些值。這種方式，我們控制worker的數(shù)量和JobQueue的大小，所以我們可以很快的改變這些值，而不需要重新部署集群。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

直接結(jié)果

我們部署了之后，立馬看到了延時(shí)降到微乎其微的數(shù)值，并未我們處理請(qǐng)求的能力提升很大。

Elastic Load Balancers完全啟動(dòng)后，我們看到ElasticBeanstalk 應(yīng)用服務(wù)于每分鐘1百萬(wàn)請(qǐng)求。通常情況下在上午時(shí)間有幾個(gè)小時(shí)，流量峰值超過(guò)每分鐘一百萬(wàn)次。

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

我們合理配置了我們的集群和自動(dòng)均衡配置之后，我們可以把服務(wù)器的數(shù)量降至4x EC2 c4.Large實(shí)例，并且Elastic Auto-Scaling設(shè)置為如果CPU達(dá)到5分鐘的90%利用率，我們就會(huì)產(chǎn)生新的實(shí)例。

總結(jié)

在我的書中，簡(jiǎn)單總是獲勝。我們可以使用多隊(duì)列、后臺(tái)worker、復(fù)雜的部署設(shè)計(jì)一個(gè)復(fù)雜的系統(tǒng)，但是我們決定利用Elasticbeanstalk 的auto-scaling的能力和Go語(yǔ)言開箱即用的特性簡(jiǎn)化并發(fā)。

我們僅僅用了4臺(tái)機(jī)器，這并不是什么新鮮事了。可能它們還不如我的MacBook能力強(qiáng)大，但是卻處理了每分鐘1百萬(wàn)的寫入到S3的請(qǐng)求。

處理問(wèn)題有正確的工具。當(dāng)你的 Ruby on Rails 系統(tǒng)需要更強(qiáng)大的web handler時(shí)，可以考慮下ruby生態(tài)系統(tǒng)之外的技術(shù)，或許可以得到更簡(jiǎn)單但更強(qiáng)大的替代方案。

Go并發(fā)編程之美-CAS操作

摘要： 一、前言 go語(yǔ)言類似Java JUC包也提供了一些列用于多線程之間進(jìn)行同步的措施，比如低級(jí)的同步措施有 鎖、CAS、原子變量操作類。相比Java來(lái)說(shuō)go提供了獨(dú)特的基于通道的同步措施。本節(jié)我們先來(lái)看看go中CAS操作 二、CAS操作 go中的Cas操作與java中類似，都是借用了CPU提供的原子性指令來(lái)實(shí)現(xiàn)。

go語(yǔ)言類似Java JUC包也提供了一些列用于多線程之間進(jìn)行同步的措施，比如低級(jí)的同步措施有 鎖、CAS、原子變量操作類。相比Java來(lái)說(shuō)go提供了獨(dú)特的基于通道的同步措施。本節(jié)我們先來(lái)看看go中CAS操作

go中的Cas操作與java中類似，都是借用了CPU提供的原子性指令來(lái)實(shí)現(xiàn)。CAS操作修改共享變量時(shí)候不需要對(duì)共享變量加鎖，而是通過(guò)類似樂(lè)觀鎖的方式進(jìn)行檢查，本質(zhì)還是不斷的占用CPU 資源換取加鎖帶來(lái)的開銷（比如上下文切換開銷）。下面一個(gè)例子使用CAS來(lái)實(shí)現(xiàn)計(jì)數(shù)器

go中CAS操作具有原子性，在解決多線程操作共享變量安全上可以有效的減少使用鎖所帶來(lái)的開銷，但是這是使用cpu資源做交換的。

我簡(jiǎn)單列舉了并發(fā)編程的大綱，需要詳細(xì)的私信“555”~~

Go語(yǔ)言——goroutine并發(fā)模型

參考：

Goroutine并發(fā)調(diào)度模型深度解析手?jǐn)]一個(gè)協(xié)程池

Golang 的 goroutine 是如何實(shí)現(xiàn)的？

Golang - 調(diào)度剖析【第二部分】

OS線程初始棧為2MB。Go語(yǔ)言中，每個(gè)goroutine采用動(dòng)態(tài)擴(kuò)容方式，初始2KB，按需增長(zhǎng)，最大1G。此外GC會(huì)收縮?？臻g。

BTW，增長(zhǎng)擴(kuò)容都是有代價(jià)的，需要copy數(shù)據(jù)到新的stack，所以初始2KB可能有些性能問(wèn)題。

更多關(guān)于stack的內(nèi)容，可以參見(jiàn)大佬的文章。 聊一聊goroutine stack

用戶線程的調(diào)度以及生命周期管理都是用戶層面，Go語(yǔ)言自己實(shí)現(xiàn)的，不借助OS系統(tǒng)調(diào)用，減少系統(tǒng)資源消耗。

Go語(yǔ)言采用兩級(jí)線程模型，即用戶線程與內(nèi)核線程KSE（kernel scheduling entity）是M:N的。最終goroutine還是會(huì)交給OS線程執(zhí)行，但是需要一個(gè)中介，提供上下文。這就是G-M-P模型

Go調(diào)度器有兩個(gè)不同的運(yùn)行隊(duì)列：

go1.10\src\runtime\runtime2.go

Go調(diào)度器根據(jù)事件進(jìn)行上下文切換。

調(diào)度的目的就是防止M堵塞，空閑，系統(tǒng)進(jìn)程切換。

詳見(jiàn) Golang - 調(diào)度剖析【第二部分】

Linux可以通過(guò)epoll實(shí)現(xiàn)網(wǎng)絡(luò)調(diào)用，統(tǒng)稱網(wǎng)絡(luò)輪詢器N（Net Poller）。

文件IO操作

上面都是防止M堵塞，任務(wù)竊取是防止M空閑

每個(gè)M都有一個(gè)特殊的G，g0。用于執(zhí)行調(diào)度，gc，棧管理等任務(wù)，所以g0的棧稱為調(diào)度棧。g0的棧不會(huì)自動(dòng)增長(zhǎng)，不會(huì)被gc，來(lái)自os線程的棧。

go1.10\src\runtime\proc.go

G沒(méi)辦法自己運(yùn)行，必須通過(guò)M運(yùn)行

M通過(guò)通過(guò)調(diào)度，執(zhí)行G

從M掛載P的runq中找到G，執(zhí)行G

go語(yǔ)言--Goroutines

1、goroutine：在go語(yǔ)言中，每一個(gè)并發(fā)的執(zhí)行單元叫做goroutine，如果一個(gè)程序中包含多個(gè)goroutine，對(duì)兩個(gè)函數(shù)的調(diào)用則可能發(fā)生在同一時(shí)刻

2、main goroutine：當(dāng)一個(gè)程序啟動(dòng)時(shí)，其主函數(shù)即在一個(gè)單獨(dú)的goroutine中運(yùn)行，我們叫他為main gorountine

3、go goroutine：新的goroutine會(huì)用go語(yǔ)句來(lái)創(chuàng)建，go+函數(shù)名，go語(yǔ)句會(huì)使其語(yǔ)句中的函數(shù)在一新創(chuàng)建的goroutine中運(yùn)行，而go語(yǔ)句本身會(huì)迅速地完成

4、goroutine的退出：主函數(shù)返回時(shí)，所有的goroutine都會(huì)被直接打斷，程序退出，除了從主函數(shù)退出或者終止程序之外，沒(méi)有其他方法能夠讓一個(gè)goroutine來(lái)打斷另一個(gè)的執(zhí)行，但是可以通過(guò)另一種方式來(lái)實(shí)現(xiàn)這個(gè)目的，通過(guò)goroutine之間的通信來(lái)讓一個(gè)goroutine請(qǐng)求其他的goroutine，并讓請(qǐng)求的goroutine自行結(jié)束執(zhí)行

新聞標(biāo)題：go語(yǔ)言并發(fā)方法 go語(yǔ)言并發(fā)編程實(shí)戰(zhàn)
瀏覽路徑：http://muchs.cn/article16/doscedg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、網(wǎng)站策劃、微信公眾號(hào)、移動(dòng)網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化

廣告

聲明：本網(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)