Flume的事务机制和可靠性

 实际开发中&＃xff0c;或者在面试中&＃xff0c;总会碰到诸如Flume如何保证数据传输的完整性&＃xff1f;

     一&＃xff1a;Flume的事务机制

     所以这就不得不提Flume的事务机制&＃xff08;类似数据库的事务机制&＃xff09;&＃xff1a;Flume使用两个独立的事务分别负责从soucrce到channel&＃xff0c;以及从channel到sink的事件传递。比如以上面一篇博客中的事例为例&＃xff1a;spooling directory source 为文件的每一行创建一个事件&＃xff0c;一旦事务中所有的事件全部传递到channel且提交成功&＃xff0c;那么source就将该文件标记为完成。同理&＃xff0c;事务以类似的方式处理从channel到sink的传递过程&＃xff0c;如果因为某种 原因使得事件无法记录&＃xff0c;那么事务将会回滚。且所有的事件都会保持到channel中&＃xff0c;等待重新传递。

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

     Flume的事务机制&＃xff0c;总的来说&＃xff0c;保证了source产生的每个事件都会传送到sink中。但是值得一说的是&＃xff0c;实际上Flume作为高容量并行采集系统采用的是At-least-once&＃xff08;传统的企业系统采用的是exactly-once机制&＃xff09;提交方式&＃xff0c;这样就造成每个source产生的事件至少到达sink一次&＃xff0c;换句话说就是同一事件有可能重复到达。这样虽然看上去是一个缺陷&＃xff0c;但是相比为了保证Flume能够可靠地将事件从source,channel传递到sink,这也是一个可以接受的权衡。如上博客中spooldir的使用&＃xff0c;Flume会对已经处理完的数据进行标记。

    三&＃xff1a;Flume的批处理机制

     为了提高效率&＃xff0c;Flume尽可能的以事务为单位来处理事件&＃xff0c;而不是逐一基于事件进行处理。比如上篇博客提到的spooling directory source以100行文本作为一个批次来读取&＃xff08;BatchSize属性来配置&＃xff0c;类似数据库的批处理模式&＃xff09;。批处理的设置尤其有利于提高file channle的效率&＃xff0c;这样整个事务只需要写入一次本地磁盘&＃xff0c;或者调用一次fsync&＃xff0c;速度回快很多。