我最近開始在 Google PubSub 上作業，并使用相同的推送訂閱在云運行實體之間傳輸資料。
在測驗期間，我注意到在少數情況下發布和訂閱之間存在延遲。所以我直接使用了 REST API 呼叫，而不是通過 PubSub 發送。
請幫助我理解以下 2 項：
- 哪個更快？
- 哪個有效？
謝謝你，
KK
uj5u.com熱心網友回復：
直接在 Cloud Run 實體之間進行通信與通過 Cloud Pub/Sub 進行通信可能比僅使用更快的方式具有更多影響。在“良好”的情況下，您的發布者和訂閱者都已啟動并正在運行且沒有過載，直接通信可能會更快。
使用 Pub/Sub 的原因主要有兩點：可發現性和可靠性。對于可發現性，是否保證您的發布 Cloud Run 實體將始終知道訂閱 Cloud Run 實體的 URL？資料的傳輸總是一對一的嗎？您是否曾擁有多個想要接收訊息的 Cloud Run 實體？如果是這樣，您希望如何更新發布者以向兩者發送訊息？如果您直接進行通信，則可能必須向每個目標 Cloud Run 實體發出單獨的請求并等待兩者的回應。如果您使用 Cloud Pub/Sub，這將為您處理：
使用 Pub/Sub 的另一個主要原因是可靠性。如果訂閱 Cloud Run 實體停機或過載，您的發布 Cloud Run 實體會做什么？它會緩沖訊息嗎？將它們寫入持久存盤？它如何管理緩沖區或存盤并最終重新傳遞訊息？如果 Cloud Run 實體在此期間重啟怎么辦？使用 Cloud Pub/Sub，您通常無需擔心任何這些注意事項，因為該服務旨在提供高可用性并在需要時快速緩沖訊息，而不會影響發布者的性能。
因此，如果速度是您唯一關心的問題，并且您從一個 Cloud Run 實體到另一個實體的請求始終是一對一的，那么您將始終知道目標 Cloud Run 實體的地址，并且無需實施更復雜的方法就可以了緩沖（基本上，保證最多一次交付），然后直接呼叫可能沒問題。
但是，如果需要考慮這些因素中的任何一個，那么 Cloud Pub/Sub 將是一個更好的選擇。由于它跳過多個步驟，因此它可能會更慢。您可能可以采取一些措施來確保最小化延遲。兩種常見的是：
- 確保您只實體化發布者客戶端一次并重用它，而不是為每次發布重新創建客戶端。
- 在您的發布者批處理設定中，將 maxMessages 設定為 1，以便在通過呼叫 接收到每條訊息后立即發送
publish。如果您的訊息吞吐量相對較低，這將很有幫助。如果您的吞吐量很高，那么關鍵是確保您不要同步等待發布的結果，尤其是在回圈發布訊息的情況下。通過異步等待，您將能夠批量處理更多訊息，從而更有效地發送它們。
所以對于有效的問題，沒有單一的答案。這在很大程度上取決于用例和所需的行為。但很可能，從效率的角度來看，您必須完成可靠的交付作業量，Pub/Sub 是更好的選擇。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/314032.html
上一篇：創建路徑以從陣列中獲取特定物件