Transmitting Event Streams

最後一個章節是 串流處理 (stream processing)，Day 23 ~ Day 27 講的 批次處理 (batch processing) 之輸入都是有限的，而串流處理要做的就是處理無限的輸入，放棄固定以時間片段執行，選擇當事件發生時執行。

但其實我們可以把時間切成極細的片段（每 1 奈秒），這樣批次處理就會等於串流處理了 XDD。

Messaging Systems

一般來說，串流 (stream) 是指會隨著時間逐漸增加且可用的數據，此概念有被運用在很多地方，如 Unix 系統的 stdin 和 stdout ，程式語言的 lazy list 等等。

事件 (event) 可以是字串、JSON、或二進位數據，端看系統使用的編碼方式為何，而事件代表的意義很廣泛，以串流處理的角度來看，事件是按日歷鐘時間逐漸發生的數據；以 Java 的 FileInputStream 來看，事件就是每一行的 byte；以 Day 23 的 log 分析例子來看，事件就是每一筆 log，它們都是相同的概念：一個小的、自我包含的、不可變的對象。

在串流處理的術語中，一個事件被 生產者 (producer) 產生，然後會有多個 消費者 (consumer) 處理事件，相關的事件通常被組合到同一個 topic 中。

直接訊息傳遞

一般常見方法是使用 訊息系統 (messaging system) 來通知消費者有新事件發生，然而有一些訊息系統不會透過中間層節點，生產者透過網路直接將訊息通知消費者，像無代理訊息系統 ZeroMQ 和 nanomsg 透過 TCP 或 IP multicast 實作 發佈/訂閱 (publish/subscribe) 模型。

訊息代理

另一個被廣泛使用的寄送訊息之選擇就是 訊息代理 (message broker) 啦，生產者和消費者都透過 broker 作業。

當多個消費者想從同一個 topic 讀取訊息時，這裡有 2 種訊息傳遞模式可選擇，如下圖 11-1：

• Load balancing

  每一條訊息只會傳遞給其中之一個消費者，所以消費者可以並行分散的處理訊息，適合用在訊息處理是昂貴的場景上。

• Fan-out

  每一條訊息都會傳遞給所有消費者，這個就像同時從同一個輸入資料中執行多個批次處理作業一樣，消費者之間不會彼此干擾。

但實務上會組合這 2 個模式，像 Kafka 就能多個消費者群組註冊同一個 topic，每條訊息都會傳遞給這些消費者群組，消費者群組中是並行的接收訊息來處理。

未完喔！