前言

昨天我們講了什麼是Event Broker與它的優點所在。
讓大家瞭解Event Broker是一種非常強大的design pattern，不僅能有效的接收並處理event，也能解耦publisher與subscriber間的相依性。
接著我們用Pub-Sub例子來講Event Broker是怎麼運作的。

好~讓我們開始吧!

Event Broker運作流程

我們用電商平台的訂單系統為範例:

當使用者在平台的購物車完成結帳，Publisher會產生一個訂單的event(ex. orderCreated)，接著將這個event發送給Event Broker進行下一步的處理。

Event Broker收到orderCreated這筆event後開始處理:

1. Event Routing: event broker會根據orderCreated的topic分發到有subscribe這個topic的subscriber
2. Event Distribution: 如果有多個subscriber subscribe這個topic，Event Broker可以同時分送給多個subscriber，來確保所有需要這個event的service能夠及時收到event
3. Event Confirm and Retry: 如果subscriber在一段時間內沒有回報給event broker，告知已經處理完成的話，event broker會認為event可能遺失，會重送event給subscriber。若重送多次event還沒有收到回報訊息，會記錄起來方便維運人員分析問題

Event Broker應用場景

• 及時的數據處理
• 微服務(Microservices)的架構
• Event Driven Architecture
• 監控系統
• 資料同步

總結

Event Broker的整體流程包含event的routing、distribution、confirm與retry等多個重要的步驟。這些流程能保證EDA有效率的運作，讓系統的靈活度大幅提升，並保證資料的同步，確保資料的一致性。
今天簡單用訂單系統當作例子讓大家知道Event Broker內部實際做了哪些操作，確保subscriber能夠接到event，也能監督subscriber是否有完成處理。

好了~今天就到這邊!!

Reference

• 事件驅動架構介紹 (Event-Driven)