根据Flume User Guild文档的说明，典型的Flume数据流模型如下所示：

3.1 Source
Source负责接收并解析（如反序列化）来自外部源的events数据，并将解析后的数据发送给与它连接的一个或多个channel(s)。
几点说明如下：
1) 外部源发往Source的数据格式必须与Flume配置文件中指定的Source Type保持一致。比如，若配置Flume的Source类型为thrift，则发来的数据必须按thrift协议打包。
2) 目前Source支持的接收外部源数据的方式包括RPC（如将Source配置为Avro方式时，可通过Avro客户端以RPC方式向Flume发送数据）、Thrift源、HTTP源、Exec源、JMS源、Seq源（类似于计数生成器，它会持续生成event，主要用于测试），等等。具体支持的Source列表及使用实例，可参考官方文档Flume Sources的说明。
3) 在同一个agent进程中，若source配置了多个channels，此时，根据业务需求，可为source配置不同的event路由策略，常见的channel selector包括replicating和multiplexing两种，其中，前者为默认策略，表示来自source的events会同时发往与它连接的所有channels（显然这种情况会更耗内存或磁盘）；而后者表示source的events只会发送到特定的channel(s)，具体而言，source通过其配置项selector.header指定路由决策字段的key，通过配置项selector.mapping.<hdr-value>指定与hdr-value匹配的events将要发往的channel，其中，<hdr-value>是与决策字段的key关联的value。具体实例可参考Flume Channel Selectors文档的说明。
4) 可以借助source. Interceptors修改或过滤event，细节可参考文档Flume Interceptors。
5) 自定义实现的Source也可以作为plugin集成到Flume中。

3.2 Channel
Channel是个被动的存储组件，它会维护一个内存队列或磁盘文件来保存Source发来的event直到该event被Sink消费。也即，它像队列一样连接了sources和sinks。
最常见的Channel类型是Memory Channel和File Channel，前者通过在内存队列中维护events来提高性能，但机器故障或进程退出时会丢失未被Sink消费的数据；而后者通过磁盘文件维护events，可以避免意外情况情况下的数据丢失，但显然性能会打折扣。
除Memory Channel和File Channel外，Flume还支持JBDC Channel及其它的Channel类型，细节可以查看Flume Channels文档。
几点说明如下：
1) 在使用memory类型的channel时，要意识到最大容量（capacity）问题，如果source生产events的速度超过sink的消费速度，则可能会导致channel缓冲区打满从而抛出异常。这种情况下，若向Source写数据的外部应用程序没有异常处理逻辑（ExecSource最容易出现这种情况），则数据会丢失。
2) 在使用file类型的channel并配置了多个file channels时，最好为每个channel明确配置存放events的、各自独立的文件路径，因为若采用默认的配置路径，则多个channel会竞争同一个文件锁，最终导致只有1个channel能初始化成功。
3) 可以配置memory和file混合的channel类型Spillable Memory Channel，优缺点可以查看文档，这里不赘述。
4) 自定义实现的Channel接口可以作为plugin集成到Flume中。

4. Flume级联