《storm實戰構建大資料實時計算》storm是乙個分布式流處理系統，利用anchor和ack機制保證了所有tuple都被成功處理。如果出錯了，則可以被重傳，但是如何保證出錯的tuple只被處理一次呢？storm提供了一套事務性元件transactional topology,來解決這個問題。《從零開始學storm》 學習筆記
設計1：強順序流
每次處理乙個tuple,在當前tuple被topolopy成功處理之前，不對下乙個tuple進行處理。
例：從1開始，給每個tuple都順序加上乙個id,在處理tuple時，將處理成功的tuple-id記錄在資料庫中。下乙個tuple來時，將處理成功的tuple-id跟資料庫比較，如果相同則說明已經被處理，那麼可以忽略它；如果不相同，則說明這個tuple沒被處理過，將它的以及計算結果更新到資料庫中。這種設計最為簡單， 但是存在嚴重的問題，它每次只能處理乙個tuple，效率十分低下。
設計2：強順序batch流
每次處理一批batch .乙個batch中的tuple可以被並行處理。
例：參照設計1，我們需要保證乙個batch只被處理一次，資料庫儲存的是batch id.batch的中間計算結果先存在區域性變數中，當batch中所有的tuple都被處理完之後，判斷batch id，如果跟資料庫中的id不同，則將中間計算結果更新到資料庫中。順序性batch流也有侷限性，每次只能處理乙個batch,batch之間無法並行。
如何確定乙個batch裡面的tuple都處理完成了呢？
需要利用strorm的coordinatedbolt,coordinatedbolt具體原理如下：
coordinatedbolt主要用於如下兩個場景：
coordinatedbolt對於業務是有侵入的，要使用coordinatedbolt提供的功能，你必須要保證每個bolt傳送的每個tuple的第乙個field是request-id,這個request-id在drpc中表示乙個drpc請求；在transactional topology表示乙個batch.
設計3：storm設計storm的設計，把batch的處理分為兩個階段：
處理階段和提交階段和在一起被稱為乙個「事務」，包含「事務」處理邏輯的拓撲稱為「事務拓撲」。如果乙個batch在處理階段或提交階段有任何錯誤，則整個事務必須重新執行。
事務拓撲設計細節
如果使用事務拓撲，storm會自動處理如下事情：
事務bolt
在事務拓撲中存在3種型別的bolt.
使batchbolt變為committer batchbolt方法bolt特性：實現icommitter介面
2.transactionaltopologybuilder.setcommitterbolt(string id, ibatchbolt bolt) 將普通batchbolt轉換為committer batchbolt。
事務spout
transactionalspout介面完全不同於普通的spout介面，transactionalspout實現發射處理一批元組，並保證相同事務id總是發射相同元組的batch.
transactionalglobalcount
public class transactionalglobalcount
}
MySQL學習筆記 事務
事務是用來保證一組資料庫的操作，要麼全部成功，要麼全部失敗 應用場景較多 如銀行轉賬，訂票等。mysql的事務是在引擎層支援的，原生的myisam不支援，因此主流使用innodb引擎。原子性顧名思義，不可分割，要麼所有指令都成功，要麼所有指令都失敗 一致性事務開始前和事務結束後，資料庫的狀態都是正常...
redis學習筆記 事務
事務是乙個單獨的隔離操作 事務中的所有命令都會序列化 按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷。事務是乙個原子操作 事務中的命令要麼全部被執行，要麼全部都不執行。注 對於redis事務是否是原子性可以參考我個人挺支援作者觀點。命令說明 multi 標記乙個事務塊的開始...
sql學習筆記 事務
事務的特性 acid 原子性 乙個事物不可再分割，要麼都執行要麼都不執行 一致性 乙個事務的執行會使資料從乙個一致狀態切換到另乙個一致狀態 隔離性 乙個事務的執行不受其他事務的干擾 永續性 乙個事務一旦提交，則會永久的改變資料庫的資料 事務的建立 事務沒有明顯的開啟和結束的標記 開啟事務 set a...