1、訊息傳輸層
這一層有如下特點
有了這幾點保證之後，資料便可以在某個需要限度內全量儲存，這可將生產者和消費者解耦，並進行分布式容錯以提高可用性，可重放很重要，這確保了在必要情況下系統可進行重算。
訊息傳輸層的意義在於彈性容納並提供流計算引擎的輸入資料，並在必要時從頭開始讀取重新計算，從而獲得可靠結果。
通常使用訊息佇列如kafka來作為訊息傳輸層。
2、流處理層
這一層即是大資料流處理引擎，可用於進行流分布式實時計算。理想情況下，流處理層也應該具備如下特點
如今比較流行的大資料處理系統要數基於spark引擎的spark streaming、struct streaming還有flink、storm了。我們看看業界最常用的spark和flink在流處理這方面的高下！在延遲方面flink要更勝於spark流處理。另一方面，在一致性方面flink借鑑 chandy-lamport 分布式快照演算法實現的asynchronous barrier snapshots演算法來提供一致性保證而spark流處理無法保證。
這裡我的另一點體會是，flink是連續運算子長執行的計算模式，所以其在失敗時進行狀態重放，從斷點繼續往下執行即可，而批次的處理卻不可以，批次的重新處理時其載入的仍然是批。
二、然後我們來看幾個概念
1、冪等性
冪等性也就是指相同的操作無論執行多少次，均會產生一樣的結果。
這裡為什麼提到冪等性呢？因為分布式中的一致性通常是難以保證的，因為伴隨著分布式的一致性而來的除了耗資源還產生延遲以及網路通訊問題。所以如spark流處理輸出時是無法保證exactly-once（失敗時部分已經寫出、而還有部分未寫出，重啟時從上乙個檢查點開始，造成部分重複），這個時候可以通過冪等輸出來解決。
舉個例子，在往kafka寫出時，可以通過外部儲存的唯一鍵來輔助
設定enable.auto.commit為false，在冪等寫出時再手動提交，這樣便可保證寫入到kafka中的資料不會重複。
2、exactly-once語義
struct streaming的微批次處理模式中聲稱的exactly-once語義並不是說輸入資料只被處理一次，因為spark引擎支援任務重試（根據沿襲圖），所以很有可能task失敗導致資料重新被載入再次處理。這裡的exactly-once實際是指不管執行多少次，其最終的執行結果都是一樣的。
這個在前邊的文章已有描述，但其核心優點即是無需維護離線批計算、實時計算兩套系統，對於業務開發也只需一套程式即可，不用擔心因兩套系統導致的執行結果不一致。另外，其從頭開始計算的能力也是主要考慮的其不足的一點。
大資料架構中的流式架構和Kappa架構
1.流式架構 流式架構在大資料中應用十分廣泛，在傳統大資料架構的基礎上，流式架構非常激進，直接取消了批處理操作，資料全程以資料流的方式進行處理，所以在資料接入端沒有了etl操作，轉而替換為資料通道。而流式架構的優點十分明顯，流式架構的優點就是沒有十分麻煩的etl過程，資料的實效性非常高。當然，流式架...
遊戲引擎的層級架構
在遊戲程式的領域中，最常聽到的專有名詞，可以說是非game engine 遊戲引擎 莫屬了。聽起來是個很炫很酷的名詞，但其實遊戲引擎一詞經常被過度泛稱與誤用。所謂的遊戲引擎架構，由低階 low level 至高階 high level 可細分為以下三個層級 layer 繪圖 api，負責掌管程式與硬...
Dubbo架構的特點
1 註冊中心 負責服務位址的註冊於查詢 相當於目錄服務，服務提供者與消費者 只在啟動時與註冊中心互動，註冊中心不 請求，壓力較小 2 監控中心 負責統計各服務呼叫次數，呼叫時間等 統計先在記憶體彙總後，每分鐘一次傳送到監控中心伺服器，並以報表展示 3 服務提供者 向註冊中心，註冊其提供的服務 並匯報...