認識 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: 訂閱者， 訂閱訊息的一個單位

---

❖ 簡易情境

• 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 的方式，分別為 PULL 跟 PUSH.

• 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，都與新建立的無關