flink kafka sink執行兩階段提交的流程圖大致如下：
假設一種場景，從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進行真正的事務commit。
以上便是兩階段的完整流程，提交過程中如果失敗有以下兩種情況
pre-commit失敗，將恢復到最近一次checkpoint位置
一旦pre-commit完成，必須要確保commit也要成功
因此，所有opeartor必須對checkpoint最終結果達成共識：即所有operator都必須認定資料提交要麼成功執行，要麼被終止然後回滾。
redis 事務簡述
一 什麼是redis事務？一組命令的執行看作乙個集體，在這執行中間，這一組命令按順序依次執行，中間不被打斷或干擾。乙個佇列中一次性，順序性，排他性的執行一系列命令。二 事務的基本操作 開啟事務 multi 作用 開啟事務，此條命令執行，後續命令均加入事務中。執行事務 exec 事務結束位置，即執行事...
事務 Transaction 簡述
一 定義 二 應用場景 設想網上購物的一次交易，其付款過程至少包括以下幾步資料庫操作 正常的情況下，這些操作將順利進行，最終交易成功，與交易相關的所有資料庫資訊也成功地更新。但是，如果在這一系列過程中任何乙個環節出了差錯，例如在更新商品庫存資訊時發生異常 該顧客銀行帳戶存款不足等，都將導致交易失敗。...
簡述Redis的事務
簡單理解，可以認為 redis 事務是一些列 redis 命令的集合，並且有如下兩個特點 1.事務是乙個單獨的隔離操作 事務中的所有命令都會序列化 按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷。2.事務是乙個原子操作 事務中的命令要麼全部被執行，要麼全部都不執行。一般來說...