本节书摘来自华章出版社《Flume日志收集与MapReduce模式》一书中的第1章，第1.1节，作者 ［美］ 史蒂夫·霍夫曼（Steve Hoffman）斯里纳特·佩雷拉（Srinath Perera），更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.1　Flume 0.9

Flume是在2011年被首次引入到Cloudera的CDH3分发中的。它由一套工作守护进程（代理）构成，这些守护进程是通过Zookeeper（一个配置与协调系统）根据一个或多个集中的Master配置而成的。在Master上，你可以在Web UI中查看代理状态，也可以以集中的方式在UI或是通过命令行Shell的方式取出配置（这两种方式都是通过Zookeeper与工作代理进行通信的）。
可以通过3种模式发送数据，分别叫作Best Effort（BE）、Disk Failover（DFO）以及End-to-End（E2E）。Masters用于E2E模式，而多个Master配置尚不成熟，因此通常情况下只会使用一个Master，这使得其成为了E2E数据流失败的主要原因。Best Effort见名知意，代理会尝试并发送数据，如果无法发送，那么数据就会被丢弃。这种模式非常适合于度量等场景，一些差异是可以被接受的，因为新数据很快就会到来。DiskFailover模式会将无法发送的数据存储到本地磁盘上（有时也存储到本地数据库中），并且会不断重试，直到可以将数据发送到数据流中的下一个接受者为止。这对于计划好（或计划外）的断电场景很方便，只要有足够的本地磁盘能够缓存负载即可。
2011年6月，Cloudera将Flume项目的控制权交给了Apache基金会。2012年，Flume项目就从孵化状态变成了顶级项目。在孵化的这一年中，开发人员就已经开始基于Star Trek Themed标签对Flume进行重构，并创建了Flume-NG（Flume the Next Generation）。