先来看一下官方解释 Flume是一个高可用，高可靠，分布式的海量日志采集、聚合和传输的系统，能够有效的收集、聚合、移动大量的日志数据。 其实通俗一点来说就是Flume是一个很靠谱，很方便、很强的日志采集工具。 他是目前大数据领域数据采集最常用的一个框架 为什么它这么香呢？ 主要是因为使用Flume采集数据不需要写一行代码，注意是一行代码都不需要，只需要在配置文件中随便写几行配置Flume就会死心塌地的给你干活了，是不是很香？ 看这个图，这个属于Flume的一个非常典型的应用场景，使用Flume采集数据，最终存储到HDFS上。

它有一个简单、灵活的基于流的数据流结构，这个其实就是刚才说的Agent内部有三大组件，数据通过这三大组件流动的 具有负载均衡机制和故障转移机制，这个后面我们会详细分析 一个简单可扩展的数据模型(Source、Channel、Sink)，这几个组件是可灵活组合的

前面我们分析了Flume的典型常见应用场景，下面来看一下Flume的高级应用场景

看这个图，这个图里面主要演示了Flume的多路输出，就是可以将采集到的一份数据输出到多个目的地中，不同目的地的数据对应不同的业务场景。

下面来详细分析一下 这个图里面一共有两个Agent，表示我们启动了2个Flume的代理，或者可以理解为了启动了2个flume的进程。 首先看左边这个agent，给他起个名字叫 foo 这里面有一个source，source后面接了3个channel，表示source读取到的数据会重复发送给每个channel，每个channel中的数据都是一样的 针对每个channel都接了一个sink，这三个sink负责读取对应channel中的数据，并且把数据输出到不同的目的地， sink1负责把数据写到hdfs中 sink2负责把数据写到一个Java消息服务数据队列中 sink3负责把数据写给另一个Agent

所以sink3就把数据输出到了Agent bar中 在Agent bar中同样有三个组件，source组件其实就获取到了sink3发送过来的数据，然后把数据临时存储到自己的channel4中，最终再通过sink组件把数据写到其他地方。 这就是这个场景的应用，把采集到的一份数据重复输出到不同的目的地中

接着再看下面这张图，这张图主要表示了flume的汇聚功能，就是多个Agent采集到的数据统一汇聚到一个Agent

下面来详细分析一下， 这个图里面一共启动了四个agent，左边的三个agent都是负责采集对应web服务器中的日志数据，数据采集过来之后统一发送给agent4，最后agent4进行统一汇总，最终写入hdfs。 这种架构的好处是后期如果要修改最终数据的输出目的地，只需要修改agent4中的sink即可，不需要修改agent1、2、3。 但是这种架构也有弊端，

Flume的三大核心组件：

Source：数据源 Channel：临时存储数据的管道 Sink：目的地 接下来具体看一下这三大核心组件都是干什么的

Source：数据源：通过source组件可以指定让Flume读取哪里的数据，然后将数据传递给后面的channel

Flume内置支持读取很多种数据源，基于文件、基于目录、基于TCP\UDP端口、基于HTTP、Kafka的等等、当然了，如果这里面没有你喜欢的，他也是支持自定义的 在这我们挑几个常用的看一下：

实现文件监控，可以实时监控文件中的新增内容，类似于linux中的tail -f 效果。 在这需要注意 tail -F 和 tail -f 的区别 tail -F 等同于–follow=name --retry，根据文件名进行追踪，并保持重试，即该文件被删除或改名后，如果再次创建相同的文件名，会继续追踪 tail -f 等同于–follow=descriptor，根据文件描述符进行追踪，当文件改名或被删除，追踪停止 在实际工作中我们的日志数据一般都会通过log4j记录，log4j产生的日志文件名称是固定的，每天定时给文件重命名 假设默认log4j会向access.log文件中写日志，每当凌晨0点的时候，log4j都会对文件进行重命名，在access后面添加昨天的日期，然后再创建新的access.log记录当天的新增日志数据。 这个时候如果想要一直监控access.log文件中的新增日志数据的话，就需要使用tail -F

采集指定端口(tcp、udp)的数据，可以读取流经端口的每一行数据

采集文件夹里新增的文件

从Kafka消息队列中采集数据

Channel：接受Source发出的数据，可以把channel理解为一个临时存储数据的管道 Channel的类型有很多：内存、文件，内存+文件、JDBC等

接下来我们来分析一下

使用内存作为数据的存储 优点是效率高，因为就不涉及磁盘IO 缺点有两个

1：可能会丢数据，如果Flume的agent挂了，那么channel中的数据就丢失了。 2：内存是有限的，会存在内存不够用的情况

使用文件来作为数据的存储 优点是数据不会丢失 缺点是效率相对内存来说会有点慢，但是这个慢并没有我们想象中的那么慢， 所以这个也是比较常用的一种channel。

使用内存和文件作为数据存储，即先把数据存到内存中，如果内存中数据达到阈值再flush到文件中

优点：解决了内存不够用的问题。 缺点：还是存在数据丢失的风险

Sink：从Channel中读取数据并存储到指定目的地

Sink的表现形式有很多：打印到控制台、HDFS、Kafka等，

注意：Channel中的数据直到进入目的地才会被删除，当Sink写入目的地失败后，可以自动重写，不会造成数据丢失，这块是有一个事务保证的。

常用的sink组件有：

将数据作为日志处理，可以选择打印到控制台或者写到文件中，这个主要在测试的时候使用

将数据传输到HDFS中，这个是比较常见的，主要针对离线计算的场景

将数据发送到kafka消息队列中，这个也是比较常见的，主要针对实时计算场景，数据不落盘，实时传输，最后使用实时计算框架直接处理。