認識 Google Cloud Pub/Sub

初探 Google PubSub,根據官方文件來做筆記

🔗 What is Google Cloud Pub/Sub?

Pub/Sub 是一種 messaging service,適合拿來做不同服務間的 訊息傳遞 或者 狀態同步

❖ 主要名詞認識

  • Message: 要傳送的 data
  • Topic: 主題,是一個可以被訂閱訊息的實體
  • Subscription: 訂閱,連結 Topic 跟 Subscriber 之間的實體,接收以及處理發佈訊息到 Topic
  • Publisher: 發布者,提供並且發送訊息到 Topic 的單位
  • Subscriber: 訂閱者, 訂閱訊息的一個單位

❖ 簡易情境

PubSub 使用情境範例圖
  • A, B 同時可以 publish message 到相同的 Topic
  • 該 Topic 有兩個 subscriptions
    • Subscription 1 有 2 個訂閱者
    • Subscription 2 有 1 個訂閱者

❖ Performance

主要由 Scalability, Availability, Latency 來決定

  • Scalability

    • publisher 的數量
    • topics 的數量
    • subscriptions 的數量
    • message 的數量
    • message 的 size 大小
    • … etc
  • Latency 主要有兩個因素

    • 確認已發佈的時間:也就是 ack 已發送的訊息的延遲
    • 訊息發送給訂閱者所需的時間

❖ Message 的生命週期

  1. publish 一則 message
  2. message 被寫入 storage
  3. Google Pub/Sub 送一個 ack 給 publisher 說我收到你要傳遞的 message ,並且已經發給所有的訂閱者
  4. 在訊息寫入 storage 的同時 Google Pub/Sub 傳給訂閱者
  5. 訂閱者傳送 ack 給 Google Pub/Sub 說我在處理 message
  6. 訂閱者至少 ack 過每一則訂閱的 message 之後, Google Pub/Sub 就會從 storage 移除

❖ Subscriber 操作面

對訂閱者來說有兩種處理 Message 的方式,分別為 PULLPUSH.

  • push

    • 送一個 request 給 App 的 endpoint 說我要傳訊息來。
    • 以這個 endpoint return [200, 201, 204, or 102] 來判定為 ack, 如果不是就會一直被打直到這個訂閱所設置的最大 retention time 為止
    • 動態調整 push 的 request,根據拿到的狀態碼來調整。
  • pull

    • 視為被動的取得訂閱佇列 (subscription queue) 中的 Message

兩者機制要怎麼選用,有以下建議

  • push

    • 低流量情形 (< 10,000/second)
    • Legacy push webhook
    • App Engine 的訂閱者
  • pull

    • 大量的訊息 (many more than 1/second)
    • 效能跟訊息遞送因素很重視者
    • 公開的 Https Endpoint

❖ Subscription 的生命週期

  • 31 天內沒有被 pull or push 就會被自動刪除,或者經過手動操作被刪除
  • 訂閱的名字沒有絕對關係,用同樣的名字也會被視為兩者不同的訂閱(情境可能是:刪除前,刪除後)
  • 刪除後就算有大量還沒寄出的訊息,或者是 Backlog,都與新建立的無關

See more