① docommit檢查channel中是否還有足夠的空間來容納putlist中的所有資料，
②如果有docommit就成功了，putlist中的所有資料就會進入到channel中並清空putlist中的資料。
③如果檢測的時候發現channel中的空間不足以容納putlist中的資料的時候，事務就會進行回滾（所謂的回滾就是等一定的時間後，再嘗試將putlist中的資料傳送到channel）。
注：flume中有兩種source，一種名為pullable source，taildirsource就是這種source，這種source是主動拉取資料，而不是由資料來源推送過來的，這種source在回滾等待的過程中source不會繼續拉取資料。還有一種是eventdriven source，這種source中的資料是由資料來源主動不停的提交資料，在事務回滾的時候，會停止接收資料，這時有可能會產生資料丟失，這種丟失並不是發生在flume內部，而是發生在flume和資料來源之間。
1.2 take 事務流程
flume的事務機制，總的來說，保證了source產生的每個事件都會傳送到sink中。但是值得一說的是，實際上flume作為高容量並行採集系統採用的是at-least-once（傳統的企業系統採用的是exactly-once機制）提交方式，這樣就造成每個source產生的事件至少到達sink一次，換句話說就是同一事件有可能重複到達。這樣雖然看上去是乙個缺陷，但是相比為了保證flume能夠可靠地將事件從source,channel傳遞到sink,這也是乙個可以接受的權衡。如上部落格中spooldir的使用，flume會對已經處理完的資料進行標記。
為了提高效率，flume盡可能的以事務為單位來處理事件，而不是逐一基於事件進行處理。比如上篇部落格提到的spooling directory source以100行文字作為乙個批次來讀取（batchsize屬性來配置，類似資料庫的批處理模式）。批處理的設定尤其有利於提高file channle的效率，這樣整個事務只需要寫入一次本地磁碟，或者呼叫一次fsync，速度回快很多。
Flume學習筆記（三）Flume 內部機制
本篇是 flume 學習筆記的第三篇，主要整理 flume 的事務機制以及 event 如何在 agent 中流轉的整個過程。為了保證資料的不丟失，flume 框架在 agent 程序中加入了倆個事物機制，分布為 source channel 和 channel sink，示意圖如下 take 事務...
Flume調優機制
調節flume的配置引數 1.source 1 增加source元件的數量，可以增大source讀取資料的能力 2 batchsize引數決定source一次批量傳輸到channel的event數量 將引數batchsize的值調大，可以調高source搬運event的能力。2.channel 1 ...
Flume 事務與傳輸流程
doput 將批資料先寫入臨時緩衝區 putlist docommit 檢查 channel 記憶體佇列是否足夠合併 dorollback channel 記憶體佇列空間不足，回滾資料 dotake 將資料取到臨時緩衝區 takelist，並將資料傳送到 hdfs docommit 如果資料全部傳送...