似乎到處都在討論從通道讀取應(yīng)該始終是阻塞操作。態(tài)度似乎是這就是Go的方式。這有一定道理，但我正在嘗試弄清楚如何從渠道匯總內(nèi)容。比如發(fā)送http請求。假設(shè)我有一個生成數(shù)據(jù)流的管道設(shè)置，所以我有一個生成隊列/點流的通道。然后我可以讓一個 goroutine 監(jiān)聽這個通道并發(fā)送一個 HTTP 請求來將它存儲在一個服務(wù)中。這有效，但我正在為每個點創(chuàng)建一個 http 請求。我發(fā)送的端點也允許我批量發(fā)送多個數(shù)據(jù)點。我想做的是讀取盡可能多的值，直到我阻塞通道。組合它們/發(fā)送單個 http 請求。然后在頻道上阻塞，直到我可以再次閱讀。這就是我在 C 中使用線程安全隊列和 select 語句完成任務(wù)的方式。在可能的情況下基本上刷新整個/隊列緩沖區(qū)。這是一種有效的技術(shù)嗎？似乎 go select 語句確實給了我類似于 C 的選擇的東西，但我仍然不確定通道上是否有“非阻塞讀取”。編輯：我也愿意接受我想要的可能不是 Go Way，但不斷粉碎不間斷的 http 請求對我來說似乎也是錯誤的，尤其是如果它們可以聚合的話。如果有人有一個很酷的替代架構(gòu)，但我想避免諸如神奇地緩沖 N 個項目或等待 X 秒直到發(fā)送之類的事情。
2 回答
烙印99
TA貢獻(xiàn)1829條經(jīng)驗 獲得超13個贊
Dewy Broto 為您的問題提供了很好的解決方案。這是一個簡單直接的解決方案，但我想更廣泛地評論您如何為不同的問題尋找解決方案。
Go 使用通信順序進(jìn)程代數(shù) (CSP) 作為通道、選擇和輕量級進(jìn)程 ('goroutines') 的基礎(chǔ)。CSP保證事件的順序；當(dāng)您通過做出選擇（又名select）這樣做時，它只會引入非確定性。有保證的排序有時被稱為“先發(fā)生”——它使編碼比替代（廣受歡迎）的非阻塞風(fēng)格簡單得多。它還為創(chuàng)建組件提供了更多空間：通過渠道以可預(yù)測的方式與外部世界交互的長期功能單元。
或許關(guān)于頻道阻塞的討論在人們學(xué)習(xí)圍棋的方式上設(shè)置了心理障礙。我們在 I/O 上阻塞，但我們在通道上等待。如果系統(tǒng)作為一個整體有足夠的并行松弛度（即其他活動的 goroutines）來保持 CPU 忙碌，那么等待通道是不會皺眉的。
可視化組件
所以，回到你的問題。讓我們從組件的角度考慮它，您有許多需要探索的點來源。假設(shè)每個源都是一個 goroutine，然后它在您的設(shè)計中形成一個帶有輸出通道的組件。Go 允許共享通道端，因此許多源可以安全地按順序?qū)⑺鼈兊狞c交錯到單個通道上。您無需執(zhí)行任何操作 - 這就是頻道的工作方式。
Dewy Broto 描述的批處理功能本質(zhì)上是另一個組件。作為一種學(xué)習(xí)練習(xí)，以這種方式表達(dá)它是一件好事。批處理組件具有一個點輸入通道和一個批次輸出通道。
最后，HTTP i/o 行為也可以是一個具有一個輸入通道而沒有輸出通道的組件，僅用于接收整批點然后通過 HTTP 發(fā)送它們。
以只有一個來源的簡單情況為例，這可能是這樣描述的：
+--------+ point +---------+ batch +-------------+
| source +------->-------+ batcher +------->-------+ http output |
+--------+ +---------+ +-------------+
這里的目的是在基本層面描述不同的活動。這有點像數(shù)字電路圖，這不是巧合。
你確實可以在 Go 中實現(xiàn)它，它會起作用。它甚至可能工作得很好，但在實踐中您可能更喜歡通過組合成對的組件來優(yōu)化它，必要時重復(fù)。在這種情況下，很容易將批處理器和 http 輸出結(jié)合起來，這樣做最終會得到 Dewy Broto 的解決方案。
重要的一點是 Go 并發(fā)最容易發(fā)生
(a)不要預(yù)先擔(dān)心阻塞；
(b)描述需要在相當(dāng)細(xì)粒度的級別上發(fā)生的活動（在簡單的情況下，您可以在頭腦中完成）；
(c)如有必要，通過將功能組合在一起進(jìn)行優(yōu)化。
我將把更高級的可視化移動通道端（Pi-Calculus）主題作為挑戰(zhàn)，其中通道用于將通道端發(fā)送到其他 goroutine。
- 2 回答
- 0 關(guān)注
- 204 瀏覽
添加回答
舉報
0/150
提交
取消