分布式的流處理是對無界的資料集進行連續不斷的處理，聚合，分析的過程。延遲需要盡可能的低（毫秒級或秒級）。這類框架通常採用有向無環圖（dag）來描述和處理作業拓撲。（線性處理也是一種dag）。他們一般會抽取此類系統的底層通用模型，保證其易用性，健壯性和可擴充套件性。讓開發者專注於業務實現。
流式處理框架一般會包含如下特點：
at most once：在框架中每條訊息傳輸零次或者一次，也就是說，訊息可能會丟失。
at least once：在框架中每條訊息會進行多次傳輸嘗試，至少需要有一次成功。也就是說，訊息不會丟失，但可能會重複。
exactly once：在框架中每條訊息有且只有一次，也就是說，訊息既不會丟失也不會重複。這種訊息傳遞型別是目前各大流式框架需要提供的功能。
現有流式框架的特點，比較，都可以通過以上特點來進行對比，如下圖所示：
storm，spark streaming，samza和flink的容錯性比較：
框架
容錯性storm
storm的每個操作都會把前一次操作處理訊息的確認資訊發回。topology的資料來源備份它生成的所有資料記錄（可能是幾個位元組）。當所有資料記錄的處理確認訊息收到，備份就會被安全刪除。但如果有失敗，那資料記錄就會被資料來源的資料替換。這保障了沒有資料丟失，但是會有重複。也就是at least once傳輸機制。
spark streaming
spark streaming採用的是微批的處理。它是在集群的各worker節點上處理微批。每個微批一旦失敗，重新計算即可。因為微批中資料本身的不可變性，且這些資料可以持久化，所以實現exatcly once非常簡單。
samza
samza使用的是kafka的持久化和偏移量。它監控任務的偏移量，當任務處理完訊息，相應的偏移量被刪除。偏移量會被checkpoint持久化到儲存中，並在失敗時恢復。但問題是：從上次checkpoint中修復偏移量時並不知道上游訊息是否已經被處理過，會造成重複。at least once
flink
flink的容錯機制是基於分布式快照實現的，這些快照會儲存流處理作業的狀態。如果失敗情況發生，系統可以從這些檢查點進行恢復。flink傳送barrier到資料流中。將流分成類似於微批的形式。提供exactly once機制。
ps：容錯機制會降低流處理框架的效能和吞吐量。
Storm流式處理框架概述
hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明 延遲大，響應緩慢，運維複雜。有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上storm...
流式計算的特點
1 實時性。流式大資料不僅是實時產生的，也是要求實時給出反饋結果。系統要有快速響應能力，在短時間內體現出資料的價值，超過有效時間後資料的價值就會迅速降低。2 突發性。資料的流入速率和順序並不確定，甚至會有較大的差異。這要求系統要有較高的吞吐量，能快速處理大資料流量。3 易失性。由於資料量的巨大和其價...
Storm 最火的流式處理框架
在2011年storm開源之前，由於hadoop的火紅，整個業界都在喋喋不休地談論大資料。hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明 延遲大，響應緩慢，運維複雜。有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，...