系統設計入門：Pub/Sub Pattern

發布者與訂閱者!

Publish/Subscribe pattern

簡稱Pub/Sub模型，是一種訊息傳遞的模式，由發布者與訂閱者組成。由發布者上傳訊息，但不必管會有哪些人去取用這些資料。具備at-least-once deliver, persistent storage, 資料排序(ordering)與可重複使用(replayability)的好處。

常見的Pub/Sub應用：

1. Apache Kafka
2. Cloud Pub/Sub

四個重要的Entity：

1. Publisher：負責上傳資料至Topic上。
2. Subscriber：不定時去接收訊息。
3. Topic：中介平台，存放message並識別publisher, Subscriber。
4. Message：資料。

以一個網路商店為例

最原始的作法可能由
(1) 顧客上網
(2) 下訂單進結帳與包裝系統
(3)通知user
(4)處理結帳與包裝，並通知進行發貨
(5)通知user
(6)到貨通知user

但問題就發生於，如果當公司規模擴大了，任何一個環節都可能需要做scale-out(水平擴充)。假如右上角的結帳、包裝任何一個server壞掉，可能就會導致後方流程卡住。

又或者從系統管理者角度來看，要監控各個服務也是相對麻煩的事情。

拆解成Pub/Sub的好處是透過一個中介，收集所有的topic，不論是下訂單、結帳、包裝、發貨，都可以各自成立一個topic，而且各個服務不避互相等候彼此server回應，才能往下一動繼續進行(為異步async)。

而這種設計模式，與觀察者模式(Observer Pattern)，最大的不同就在與其中有一個重要的中介角色。

如果Publishers + Subscribers = Observer Pattern

那 Publishers + Subscribers + Event Channel = Pub/Sub

兩者差異還有什麼?

1. Observer Pattern重視Subject有更新時，主動通知Observer，且通常為一個Subject對多個Observer。
   [同步更新，一對多]
2. Pub/Sub處理的點在於只要Publisher上傳資料到中介(event channel)，並不用去管後續由誰接收資料，且如果當Pub或Sub任一個server故障，也不影響運作。
   [異步更新，多對多]

其他補充資料：
1. Apache Kafka
2. Cloud Pub/Sub
3. Azure 發行者-訂閱者模式