flink、spark streaming、storm、storm trient都可以進行實時計算，但各有特點。
在大資料處理領域，批處理任務和流處理任務一般被認為是兩種不同的任務，乙個大資料框架一般會被設計為只能處理其中一種任務如何選擇實時框架：1：需要關注流資料是否需要進行狀態管理*例如storm只支援流處理任務，而mapreduce、spark只支援批處理任務。spark streaming是採用了一種micro-batch的架構，即把輸入的資料流且分為細粒度的batch，並為每乙個batch資料提交乙個批處理的spark任務，所以spark streaming本質上還是基於spark批處理系統對流式資料進行處理，和storm等完全流式的資料處理方式完全不同。
* flink通過靈活的執行引擎，能夠同時支援批處理任務和流處理任務
在執行引擎這一層，流處理系統與批處理系統最大的不同在於節點間的資料傳輸方式。
而對於乙個批處理系統，其節點間資料傳輸的標準模型是：當一條資料被處理完成後，序列化到快取中，並不會立刻通過網路傳輸到下乙個節點，當快取寫滿，就持久化到本地硬碟上，當所有資料都被處理完成後，才開始將處理後的資料通過網路傳輸到下乙個節點。
這兩種資料傳輸模式是兩個極端，對應的是流處理系統對低延遲的要求和批處理系統對高吞吐量的要求。
flink的執行引擎採用了一種十分靈活的方式，同時支援了這兩種資料傳輸模型。
flink以固定的快取塊為單位進行網路資料傳輸，使用者可以通過設定快取塊超時值指定快取塊的傳輸時機。如果快取塊的超時值為0，則flink的資料傳輸方式類似上文所提到流處理系統的標準模型，此時系統可以獲得最低的處理延遲。
如果快取塊的超時值為無限大，則flink的資料傳輸方式類似上文所提到批處理系統的標準模型，此時系統可以獲得最高的吞吐量。
同時快取塊的超時值也可以設定為0到無限大之間的任意值。快取塊的超時閾值越小，則flink流處理執行引擎的資料處理延遲越低，但吞吐量也會降低，反之亦然。通過調整快取塊的超時閾值，使用者可根據需求靈活的權衡系統延遲和吞吐量。
2：at-least-once或者exectly-once訊息投遞模式是否有特殊要求
3：對於小型獨立的專案，並且需要低延遲的場景，建議使用storm
4：如果你的專案已經使用了spark，並且秒級別的實時處理可以滿足需求的話，建議使用spark streaming
5：要求訊息投遞語義為exactly once的場景；資料量較大，要求高吞吐低延遲的場景；需要進行狀態管理或視窗統計的場景，建議使用flink
Zookeeper基本原理與應用場景
zookeeper是乙個針對大型分布式系統的可靠協調系統。提供的功能包括 配置維護 名字服務 分布式同步 組服務等。目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效 功能穩定的系統提供給使用者。zookeeper已經成為hadoop生態系統中的基礎元件。zookeeper有如下特點 最...
flink執行原理 Flink基本原理及應用場景
在大資料處理領域，批處理任務和流處理任務一般被認為是兩種不同的任務，乙個大資料框架一般會被設計為只能處理其中一種任務 例如storm只支援流處理任務，而mapreduce spark只支援批處理任務。spark streaming是採用了一種micro batch的架構，即把輸入的資料流且分為細粒度...
RabbitMQ的應用場景 基本原理介紹
訂單系統和庫存系統高耦合.引入訊息佇列 訂單系統 使用者下單後,訂單系統完成持久化處理,將訊息寫入訊息佇列,返回使用者訂單下單成功。庫存系統 訂閱下單的訊息,獲取下單訊息,進行庫操作。就算庫存系統出現故障,訊息佇列也能保證訊息的可靠投遞,不會導致訊息丟失 馬雲這下高興了 佇列和交換機有乙個建立時候指...