實際開發中，或者在面試中，總會碰到諸如Flume如何保證資料傳輸的完整性？

     一：Flume的事務機制

     所以這就不得不提Flume的事務機制（類似資料庫的事務機制）：Flume使用兩個獨立的事務分別負責從soucrce到channel，以及從channel到sink的事件傳遞。比如以上面一篇部落格中的事例為例：spooling directory source 為檔案的每一行建立一個事件，一旦事務中所有的事件全部傳遞到channel且提交成功，那麼source就將該檔案標記為完成。同理，事務以類似的方式處理從channel到sink的傳遞過程，如果因為某種 原因使得事件無法記錄，那麼事務將會回滾。且所有的事件都會保持到channel中，等待重新傳遞。

    二:Flume的At-least-once提交方式

     Flume的事務機制，總的來說，保證了source產生的每個事件都會傳送到sink中。但是值得一說的是，實際上Flume作為高容量並行採集系統採用的是At-least-once（傳統的企業系統採用的是exactly-once機制）提交方式，這樣就造成每個source產生的事件至少到達sink一次，換句話說就是同一事件有可能重複到達。這樣雖然看上去是一個缺陷，但是相比為了保證Flume能夠可靠地將事件從source,channel傳遞到sink,這也是一個可以接受的權衡。如上部落格中spooldir的使用，Flume會對已經處理完的資料進行標記。

    三：Flume的批處理機制

     為了提高效率，Flume儘可能的以事務為單位來處理事件，而不是逐一基於事件進行處理。比如上篇部落格提到的spooling directory source以100行文字作為一個批次來讀取（BatchSize屬性來配置，類似資料庫的批處理模式）。批處理的設定尤其有利於提高file channle的效率，這樣整個事務只需要寫入一次本地磁碟，或者呼叫一次fsync，速度回快很多。