Flume到底会不会丢失数据？
Source到Channel是事务性的，put事务
Channel到Sink也是事务性的，take事务
这两个环节都不可能丢失数据, 传输失败后会回滚doRollback。
但是
source：
（1）exec source ，后面接 tail -f ，这个数据也是有可能丢的。
（2）TailDir source ，这个是不会丢数据的，它可以保证数据不丢失。
channel:
采用MemoryChannel，（1）在agent宕机时候导致数据在内存中丢失；（2）Channel存储数据已满，导致Source不再写入数据，造成未写入的数据丢失；
采用FileChannel, 写入磁盘是不可能丢失数据的
sink:
不会丢失, 会重复. 例如数据已经由Sink发出，但是没有接收到响应，Sink会再次发送数据，导致数据重复
hdfs sink: flush 到 hdfs 的时候，可能由于网络原因超时导致数据传输失败，这个时候同样地调用 doRollback 方法来进行回滚，回滚的时候，由于takeList中还有备份数据，所以将takeList中的数据原封不动地还给channel，这时候就完成了事务的回滚。
但是，如果 flush 到 hdfs 的时候，数据flush了一半之后出问题了，这意味着已经有一半的数据已经发送到 hdfs 上面了，现在出了问题，同样需要调用doRollback方法来进行回滚，回滚并没有“一半”之说，它只会把整个takeList中的数据返回给channel，然后继续进行数据的读写。这样开启下一个事务的时候就容易造成数据重复的问题。
所以: Flume不会丢失数据，但是可能会数据重复
hdfs sink 优化:
调整文件滚动相关参数: 时间(1小时-2小时) or 大小128m、event个数（0禁止）具体参数：hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0
Hdfs Sink 写文件 相关配置说明
hdfs.path -> hdfs目录路径
hdfs.filePrefix -> 文件前缀。默认值FlumeData
hdfs.fileSuffix -> 文件后缀
hdfs.rollInterval -> 多久时间后close hdfs文件。单位是秒，默认30秒。设置为0的话表示不根据时间close hdfs文件
hdfs.rollSize -> 文件大小超过一定值后，close文件。默认值1024，单位是字节。设置为0的话表示不基于文件大小
hdfs.rollCount -> 写入了多少个事件后close文件。默认值是10个。设置为0的话表示不基于事件个数
hdfs.fileType -> 文件格式， 有3种格式可选择：SequenceFile, DataStream or CompressedStream
hdfs.batchSize -> 批次数，HDFS Sink每次从Channel中拿的事件个数。默认值100
hdfs.minBlockReplicas -> HDFS每个块最小的replicas数字，不设置的话会取hadoop中的配置
hdfs.maxOpenFiles -> 允许最多打开的文件数，默认是5000。如果超过了这个值，越早的文件会被关闭
serializer -> HDFS Sink写文件的时候会进行序列化操作。会调用对应的Serializer借口，可以自定义符合需求的Serializer
hdfs.retryInterval -> 关闭HDFS文件失败后重新尝试关闭的延迟数，单位是秒
hdfs.callTimeout -> HDFS操作允许的时间，比如hdfs文件的open，write，flush，close操作。单位是毫秒，默认值是10000