上面提到了批處理系統其實並不適合流式資料處理，所以我們需要一些工具來處理流式資料，當然資料庫也可以完成這個任務，生產者傳送任務到資料庫中，消費者輪詢查詢，但是當資料多了以後顯然效率上是有問題的，所以這其實是需要某些通知機制或者更為高效的模型，如下：
發布訂閱系統
生產者消費者直接通訊
訊息佇列
這裡其實就有一點豁然開朗的感覺，以前只是知道這是分布式通訊的方法，卻不知道這其實本質是流式資料處理。
我們拿訊息佇列和資料庫作對比，其實本質上和資料庫非常類似，但還是存在差異：
資料庫一般資料在明確要求刪除時刪除，而訊息佇列實在資料被消費時刪除。
如果訊息佇列內資料過多的話要麼進行限流，要麼把資料轉儲回磁碟，效率降低。
資料庫通常支援加快查詢的方法，而訊息佇列確沒有。
訊息佇列不支援查詢，但可以支援發布訂閱。
這些被視為傳統觀點，體現在jms/amqp這樣的標準中，但因為其對序列不敏感的原因，並不是只有這樣的實現。一些mq實現了日誌式的訊息佇列，它們保證資料的永續性，且保證順序，這樣就導致乙個處理時間長的任務可能阻塞後面任務的處理。比如kafka，roketmq等。因為這些原因，當訊息處理代價過高，希望並行處理，且訊息排序並不重要的時候我們可以使用jms/amqp型別的訊息佇列，但對於訊息處理很快，且對於順序要求高的任務，基於日誌的訊息佇列工作的更好。
有一點值得一提，就是在訊息佇列上客戶端出現的冪等問題，這裡的通用解決方案是偏移量，也就是客戶端在處理了每個訊息以後向mq傳送自己的偏移量，下一次的訊息處理從偏移量開始。但這樣仍有危險，就是在處理了訊息後還沒有記錄偏移量，在重新啟動後還會處理那些已經處理過的訊息，如果從mq下手問題可能不好解決，這裡我們可以在客戶端下手，保證冪等性。
寫入資料庫，快取等儲存系統，直接客戶端使用。
直接把資料推送到使用者，這樣的話人是流的最終消費者（比如熱點新聞）。
處理輸入流然後產生另乙個資料流，向批處理系統一樣最後的資料流向前兩步一樣。
我們可以發現乙個有意思的事實，就是流式資料處理和批處理的過程非常類似，但是我們仍能發現以下差異：
排序對於流式資料來說沒有什麼意義（無界的）。
容錯機制不再相同，批處理中可以選擇重新執行作業，因為輸入不變，但是流處理不可能重新執行整個資料集，因為可能已經執行了很長時間，這並不現實。
那麼流處理適用於哪些事件呢？如下：
複雜事件處理：我們可以其實就是在流中搜尋特定型別的事件，我們只需要在流處理系統中維護乙個所要匹配的特定模式即可。當發現匹配模式的事件時產生乙個輸出。
流分析：這裡我們更為關心大量事件的累計效果和統計指標。比如測量某種事件的速率，統計一段時間某個值的平均值等。
在流中搜尋：與複雜事件處理類似，不過這裡是匹配單個事件而不是模式匹配。
以上我們提到了乙個問題，就是時間段，我們知道在多機器之間時鐘是不可信任的，那麼如果確定時間段呢？首先可以使用本地時間的話，這樣的話優點是簡單，但是可能本地時鐘與客戶端存在明顯的滯後，且還有不可控的網路，這樣的話可能準確度就沒辦法保證。如果使用客戶端時間呢？顯然存在很大的問題，就是客戶端時間不可信任，如果惡意攻擊的話會有很大的安全問題。再來考慮乙個問題，我們現在需要統計每一分鐘的流量，假如現在需要統計第十分鐘的流量，十分鐘已經過去了，現在到了十一分鐘或者十二分鐘，那麼何時終止第十分鐘的計算呢，因為還可能有第十分鐘的事件沒有到來，此時有兩種方法，乙個是維護乙個全域性偏移量，當在十一分鐘收到十分鐘資料時簡單的丟棄，或者針對這個滯後時間發布乙個更正事件，顯然後者會增加系統的複雜度。
那麼時鐘問題如何解決呢，一種有效的方法是記錄多個事件戳：
根據裝置的時鐘記錄時間按發生的時間。
根據裝置的時鐘記錄將事件傳送到伺服器的時間。
根據伺服器的時鐘記錄伺服器收到事件的時間。
這樣我們可以使用第三個時間戳減去第二個時間戳，去估計出伺服器和裝置之間的偏移量，然後可以將該偏移量應用於事件時間戳。這樣我們可以確定真實發生的時間戳。這個時候我們想要確定乙個時間段就容易了，因為我們獲取了近似的真實時間戳，然後只需要選擇乙個合理的視窗用以表示時間段即可。
我們上面提到流處理的容錯機制與批處理有所不同，主要原因就是流處理系統是無界的，也就是說我們不能簡單的重啟任務，所以我們需要其他的方法。
微批處理：其實就是把流式處理看做乙個個小的批處理，這需要我們儲存一段時間內的資料，這裡通常為1s左右，顯然較小的批處理會導致更大的協調開銷，較大的微處理會導致較高的延遲，這顯然是乙個效能折中的考慮，這樣我們只需要在宕機的時候重啟這個微處理即可。
原子提交：我們可以把多個輸入當做乙個事務，並在失敗時重試，這樣我們可以丟棄掉失敗任務的部分輸出（未提交）。其實要達到相同的目的還有其他的方法，就是依賴於冪等性，我們只要保證處理乙個輸入不會造成多餘的問題就可以達到丟棄失敗任務的部分輸出。上面我們提到了偏移量可以解決這個問題。
流式資料顯然是一種非常普遍的資料場景，這也是很多相關框架崛起的原因。從處理資料中得出的見解(insights)是有價值的。這樣的見解(insights)並非都是生來平等的。一些見解(insights)在發生後不久就具有很高的價值，並且隨著時間的流逝，這種價值會迅速減少。流處理針對這樣的場景。流處理的關鍵優勢在於相比於批處理它能夠更快地提供見解(insights)。
參考：
語言處理系統
人和計算機交流資訊使用的語言稱為計算機語言或稱程式語言。計算機語言通常分為機器語言 組合語言和高階語言三類。如果要在計算機上執行高階語言程式就必須配備程式語言翻譯程式 下簡稱翻譯程式 翻譯程式本身是一組程式，不同的高階語言都有相應的翻譯程式。翻譯的方法有兩種 一種稱為 解釋 早期的basic源程式的...
批處理系統
將一批作業時間裝入磁帶，然後由監督程式道磁帶上調入記憶體，每次只能調入乙個程式並執行的是單道批處理系統 每次可調入多個程式並分時執行的是多道批處理系統。批處理系統的主要缺點 無互動能力 因為作業事先裝入磁帶即外存了 多道批處理系統採用的技術是中斷技術和多道程式技術。單道程式系統 記憶體中只能存放一道...
單道批處理系統和多道批處理系統
單道批bai處理系統的工作原理 記憶體中du只允許存放乙個作業，當前正在運zhi行的作業駐留記憶體，執行順dao序是先進先出.在單道批處理系統中，乙個作業單獨進入記憶體並獨佔系統資源，直到執行結束後下乙個作業才能進入記憶體，當進行i操作時，cpu處等待狀態。其目的是減少作業間轉換時的人工操作，從而減...