支援事務處理，支援兩階段提交
兩階段提交指的是一種協議，經常用來實現分布式事務，可以簡單理解為預提交+實際提交，一般分為協調器coordinator(以下簡稱c)和若干事務參與者participant(以下簡稱p)兩種角色。
c先將prepare請求寫入本地日誌，然後傳送乙個prepare的請求給p
p收到prepare請求後，開始執行事務，如果執行成功返回乙個yes或ok狀態給c，否則返回no，並將狀態存到本地日誌。
c收到p返回的狀態，如果每個p的狀態都是yes，則開始執行事務commit操作，發commit請求給每個p，p收到commit請求後各自執行commit事務操作。如果至少乙個p的狀態為no，則會執行abort操作，發abort請求給每個p，p收到abort請求後各自執行abort事務操作。
注：c或p把傳送或接收到的訊息先寫到日誌裡，主要是為了故障後恢復用，類似wal
flink在1.4.0版本引入了twophasecommitsinkfunction介面，封裝了兩階段提交邏輯，並在kafka sink connector中實現了twophasecommitsinkfunction，依賴kafka版本為0.11+，twophasecommitsinkfunction具體實現如下：
執行兩階段提交的流程圖大致如下：
假設一種場景，從
kafka source
拉取資料，經過一次視窗聚合，最後將資料傳送到
kafka sink
，如下圖：
jobmanager向source傳送barrier，開始進入pre-commit階段，當只有內部狀態時，pre-commit階段無需執行額外的操作，僅僅是寫入一些已定義的狀態變數即可。當chckpoint成功時flink負責提交這些寫入，否則就終止取消掉它們。
當source收到barrier後，將自身的狀態進行儲存，後端可以根據配置進行選擇，這裡的狀態是指消費的每個分割槽對應的offset。然後將barrier傳送給下乙個operator。
當window
這個operator
收到barrier
之後，對自己的狀態進行儲存，這裡的狀態是指聚合的結果
(sum
或count
的結果)
，然後將
barrier
傳送給sink
。sink
收到後也對自己的狀態進行儲存，之後會進行一次預提交。
預提交成功後，
jobmanager
通知每個
operator
，這一輪檢查點已經完成，這個時候，
kafka sink
會向kafka
進行真正的事務
以上便是兩階段的完整流程，提交過程中如果失敗有以下兩種情況
pre-commit失敗，將恢復到最近一次checkpoint位置
一旦pre-commit完成，必須要確保commit也要成功
因此，所有opeartor必須對checkpoint最終結果達成共識：即所有operator都必須認定資料提交要麼成功執行，要麼被終止然後回滾。
flink讀取有界流時開時間窗遇到的問題
有界流 不知道有沒有這個概念，我這裡用它表示以流處理的方式讀取的批資料，比如streamexecutionenvironment.fromcollection 其實這種做法或需求是比較奇怪的，要用流處理，但讀的卻是批資料，最好用流處理api處理流資料，用批處理api處理批資料。我這裡之所以有這樣 的...
關於使用pip時，遇到的問題
問題描述 當我使用pip install 需要的安裝包時，其會報如下錯誤 insecureplatformwarning could not fetch url there was a problem confirming the ssl certificate httpsconnectionpoo...
關於學習c程式設計中呼叫函式時遇到的些許問題
c程式語言對於乙個初學者來說是陌生的，所以學起來總會覺得不容易。在學習過程中，總會遇到這些那些的問題。現在說說我遇到的一些問題。一開始看書時看到的總是一些概念性的語言，然而這對於乙個理科生來說稍微琢磨便不成問題，而到後來開始講解程式設計時，就會有一些麻煩了。剛開始講的是簡單程式語言，如語法錯誤，語義...