第01講：flink 的應用場景和架構模型
第02講：flink 入門程式 wordcount 和 sql 實現
第03講：flink 的程式設計模型與其他框架比較
本課時我們主要介紹 flink 的程式設計模型與其他框架比較。
本課時的內容主要介紹基於 flink 的程式設計模型，包括 flink 程式的基礎處理語義和基本構成模組，並且和 spark、storm 進行比較，flink 作為最新的分布式大資料處理引擎具有哪些獨特的優勢呢？
我們在講解 flink 程式的程式設計模型之前，先來了解一下 flink 中的 streams、state、time 等核心概念和基礎語義，以及 flink 提供的不同層級的 api。
flink 核心概念
flink 程式設計模型和流式處理
我們在第 01 課中提到過，flink 程式的基礎構建模組是流（streams）和轉換（transformations），每乙個資料流起始於乙個或多個source，並終止於乙個或多個sink。資料流類似於有向無環圖（dag）。
在分布式執行環境中，flink 提出了運算元鏈的概念，flink 將多個運算元放在乙個任務中，由同乙個執行緒執行，減少執行緒之間的切換、訊息的序列化/反序列化、資料在緩衝區的交換，減少延遲的同時提高整體的吞吐量。
官網中給出的例子如下，在並行環境下，flink 將多個 operator 的子任務鏈結在一起形成了乙個task，每個 task 都有乙個獨立的執行緒執行。
flink 集群模型和角色
在實際生產中，flink 都是以集群在執行，在執行的過程中包含了兩類程序。
flink 資源和資源組
在 flink 集群中，乙個 taskmanger 就是乙個 jvm 程序，並且會用獨立的執行緒來執行 task，為了控制乙個 taskmanger 能接受多少個 task，flink 提出了 task slot 的概念。
我們可以簡單的把 task slot 理解為 taskmanager 的計算資源子集。假如乙個 taskmanager 擁有 5 個 slot，那麼該 taskmanager 的計算資源會被平均分為 5 份，不同的 task 在不同的 slot 中執行，避免資源競爭。但是需要注意的是，slot 僅僅用來做記憶體的隔離，對 cpu 不起作用。那麼執行在同乙個 jvm 的 task 可以共享 tcp 連線，減少網路傳輸，在一定程度上提高了程式的執行效率，降低了資源消耗。
與此同時，flink 還允許將不能形成運算元鏈的兩個操作，比如下圖中的 flatmap 和 key&sink 放在乙個 taskslot 裡執行以達到資源共享的目的。
flink 在誕生之初，就以它獨有的特點迅速風靡整個實時計算領域。在此之前，實時計算領域還有 spark streaming 和 storm等框架，那麼為什麼 flink 能夠脫穎而出？我們將分別在架構、容錯、語義處理等方面進行比較。
架構stom 的架構是經典的主從模式，並且強依賴 zookeeper；spark streaming 的架構是基於 spark 的，它的本質是微批處理，每個 batch 都依賴 driver，我們可以把 spark streaming 理解為時間維度上的 spark dag。
flink 也採用了經典的主從模式，dataflow graph 與 storm 形成的拓撲 topology 結構類似，flink 程式啟動後，會根據使用者的**處理成 stream graph，然後優化成為 jobgraph，jobmanager 會根據 jobgraph 生成 executiongraph。executiongraph 才是 flink 真正能執行的資料結構，當很多個 executiongraph 分布在集群中，就會形成一張網狀的拓撲結構。
容錯storm 在容錯方面只支援了 record 級別的 ack-fail，傳送出去的每一條訊息，都可以確定是被成功處理或失敗處理，因此 storm 支援至少處理一次語義。
flink 基於兩階段提交實現了精確的一次處理語義，我們將會在後面的課時中進行完整解析。
反壓（backpressure）
反壓是分布式處理系統中經常遇到的問題，當消費者速度低於生產者的速度時，則需要消費者將資訊反饋給生產者使得生產者的速度能和消費者的速度進行匹配。
stom 在處理背壓問題上簡單粗暴，當下游消費者速度跟不上生產者的速度時會直接通知生產者，生產者停止生產資料，這種方式的缺點是不能實現逐級反壓，且調優困難。設定的消費速率過小會導致集群吞吐量低下，速率過大會導致消費者 oom。
spark streaming 為了實現反壓這個功能，在原來的架構基礎上構造了乙個「速率控制器」，這個「速率控制器」會根據幾個屬性，如任務的結束時間、處理時長、處理訊息的條數等計算乙個速率。在實現控制資料的接收速率中用到了乙個經典的演算法，即「pid 演算法」。
flink 沒有使用任何複雜的機制來解決反壓問題，flink 在資料傳輸過程中使用了分布式阻塞佇列。我們知道在乙個阻塞佇列中，當佇列滿了以後傳送者會被天然阻塞住，這種阻塞功能相當於給這個阻塞佇列提供了反壓的能力。
本課時主要介紹了 flink 的核心語義和架構模型，並且從架構、容錯、反壓等多方位比較了 flink 和其他框架的區別，為後面我們學習 flink 的高階特性和實戰打下了基礎。
以上就是本課時的內容。在下一課時中，我將介紹「flink 常用的 dataset 和 datastream api」，下一課時見。
Flink 的程式設計模型與其他框架比較
flink 的核心語義和架構模型 我們在講解 flink 程式的程式設計模型之前，先來了解一下 flink 中的 streams state time 等核心概念和基礎語義，以及 flink 提供的不同層級的 api。flink 核心概念 streams 流 流分為有界流和無界流。有界流指的是有固定...
第4講 客戶端的編譯與遊戲的公升級
1 安裝 inno inno的安裝很簡單,直接下一步下一步就行了 有些安裝包也許有外掛程式,請注意選擇 2 認識 安裝包 安裝程式 編譯好的安裝程式所在地方 安裝指令碼 編譯安裝程式的指令碼 安裝檔案 發布好的客戶端元件和遊戲資源檔案所在地 資源檔案 安裝程式所需資源檔案 3 編譯 客戶端 一般網狐...
物件導向程式設計 C 的物件模型與虛指標
c 結構體和類 物件本質上就是一塊儲存空間，在c語言轉化為組合語言的過程中，轉化並不是自主產生的，不是一一對映，而是在編譯器的解釋下完成的，意識到這一點很重要。this指標相當於乙個基位址，而成員變數都是在該位址上的偏移。物件的分類 物件的多型性需要通過虛表和虛指標來完成。虛表是乙個儲存虛函式指標的...