在分布式領域，計算和儲存一直是兩大子領域。很多分布式理念在計算和儲存的實現中會有著完全不同的邏輯，比如我們快照，計算框架中的快照和我們平常說的儲存快照實現不同點在於**呢？筆者做為乙個研究儲存模組出身的人，最近在研讀flink流處理的部分原理，小小作番總結。很多時候，以儲存的眼光來看待計算過程中的處理過程，還是有很多不一樣的地方的。下文中，筆者將逐一介紹flink流處理的一些過程分析。額外說明一點，以下內容**於早期flink內部設計文件，可能與現今使用的flink有所差異，詳細**可見文末引用位址。
用一句簡單地話來說：通過watermark對資料重排序，來保證整體資料流的有序性。
而這裡分段資料的重排序，依靠的是資料流的watermark值。每當我們每接收到乙份資料到buffer中時，我們選定其中最新的watermark值，對buffer裡資料的時間小於此watermark值的資料在buffer中做乙個排序。然後將此排序好的資料發向下游。這裡基於的乙個原則是：時間比當前watermark訊息早的資料都已經到來了，所以我們可以大膽地把這批資料先拍好序再發出去。圖示效果如下：
最flink流任務中，會涉及到資料被多次視窗處理的問題，比如資料流被a視窗處理過有到看b視窗中做處理。我們如何來指定視窗的序列關係呢？
這裡flink採用了一種視窗逐一對齊的做法。後一視窗的起始末尾邊界與前一序處理視窗的邊界完全對齊，對應區間範圍內的結果資料同樣落位到相對應的區間視窗內。如下圖所示：
流處理與批處理相比，它的一大優勢在於它的低延時，而批處理的乙個得天獨厚的優勢是錯誤恢復容易。因為批處理任務在每次的批處理操作中會儲存住全部的輸入資料，如果出現結果算錯的情況，重新執行一次處理過程即可。而流式計算中連續不斷的資料處理，使得錯誤恢復變得複雜起來。所以假如流處理任務能夠做到快速的錯誤恢復，那麼其可用性將會大大加強。下面筆者主要闡述的是flink的錯誤恢復機制：checkpoint機制。
首先，我們假設發生了乙個流處理任務執行異常失敗的場景，然後我們準備在下一刻進行完全地恢復，重新回到失敗的那個時刻點，任務繼續往後跑。那麼在這裡我們至少有保留哪些狀態資料呢？答案是以下3點：
source的偏移量位置
當時正在流動中的資料
操作狀態資料
下面我們來看看針對這2類資料，flink內部是如何做定期checkpoint的。
flink為了實現定期的checkpoint，做的乙個核心改動是在流資料中增加乙個標記資料記錄，名為stream barrier。不同時間點插入barrier資料將流資料分隔成了多份，每份對應一次checkpoint操作，同時checkpoint會保留住資料來源source當時的偏移量資訊。如下圖所示：
當barrier標記從source流向到sink下游，並且系統受到sink端的確認訊息後，此checkpoint宣告正式完成。如果過程中需要涉及多input的輸入時，處理快的barrier流會在過程中等待落後的其它流直到它們的barrier資訊到來，然後再往下游傳輸資料，如下圖：
對於應用中所涉及的中間狀態資料，flink支援使用者自定義狀態持久化操作，然後應用程式在重新啟動的時候從外部儲存中重新恢復狀態資料。
一般情況下，為了保證狀態資料的一致性，checkpoint狀態資料的時候是同步的過程。flink在後來實現了一種非同步狀態同步的方法，主要採用的思路是拷貝原狀態的資料，然後用非同步執行緒去持久化拷貝的那份狀態資料。同時為了防止每次checkpoint大量相同狀態的資料，flink在後期也實現了增量checkpoint的功能。
感謝作者的指導！！！
明白了部分頂點處理過程
頂點處理過程 1。world transform.這是第一步，把物體放進3d座標空間裡來，才能進行下一步的 轉換和處理。2。vertex blending.這一步必須在view transform 之前完成，在view transform 之後完成的話依照我現在的理解可能會加深複雜度。頂點混合主要處...
Flink流處理的時間視窗
對於流處理系統來說，流入的訊息是無限的，所以對於聚合或是連線等操作，流處理系統需要對流入的訊息進行分段，然後基於每一段資料進行聚合或是連線等操作。訊息的分段即稱為視窗，流處理系統支援的視窗有很多態別，最常見的就是時間視窗，基於時間間隔對訊息進行分段處理。本節主要介紹flink流處理系統支援的各種時間...
ARM的中斷處理過程
1.首先就是知道 arm狀態下的通用暫存器和程式計數器，綠顏色的就是相應模式下的私有暫存器。就是說程式一般執行在系統和使用者模式下，使用的是系統和使用者模式下的通用暫存器，當有異常發生時，比如 fiq，那麼系統將切換到 fiq模式下，相應的就會採用 fiq模式下的暫存器，其中綠顏色的就是只在 fiq...