1、用户行为数据通过http接口上报到web服务器，期初由web服务器直接写入kafka，后续彻底跟业务 系统解耦，web服务型将上报的用户行为数据写入本地磁盘，再由Flume实时监控文件进行采集。 2、Flume数据采集构架采用两层agent,第一层采集、第二层聚合，使用Flume拓扑中的load balance， 充分利用资源并达到高可用。 3、第一层agent在每台web服务器上部署一个，当挂掉重启后不能丢失数据，所以我们用了 TailDirSource数据源，此数据源会记录每个文件采集到的位置，重启后会从记录的位置采集，但是此 数据源有缺陷(当文件重命名后会重复采集)，故我们需要修改此缺陷。 4、第二层聚合agent需要部署2个及以上,其中一个挂掉后，系统 可以继续运行，不丢数据，不影响结果。 5、第二层的聚合agent将数据写入kafka, 当由于某种原因比如网络问题或者kafka停服不能写入时，数 据会在第二层agent中的channel中累积，不影响第一层agent的采集，当kafka能够写入时，kafkasink 会继续消费第二层angent的channel中的数据。 6、当第二层agent全部挂掉时,数据会在第一层的采集agent中的channel中累积，不影响数据采集。 7、一点点小优化：同样的用户要进入Kafka同一个分区，为了在spark streaming中的reduceByKey时 减少shuffle数据量。我们需要在第二次的聚合agent中添加自定义的拦截器。
在flume1.7之前如果想要监控一个文件新增的内容，我们一般采用的source 为 exec tail ,但是这会有一个弊端，就是当你的服务器宕机重启后，此时数据读取还是从头开始，这显然不是我们想看到的！ 在flume1.7没有出来之前我们一般的解决思路为：当读取一条记录后，就把当前的记录的行号记录到一个文件中，宕机重启时，我们可以先从文件中获取到最后一次读取文件的行数，然后继续监控读取下去。保证数据不丢失、不重复。
具体配置文件修改为：
a1.sources.r3.command = tail -n +$(tail -n1 /root/nnn) -F /root/data/web.log | awk ‘ARGIND==1{i=$0;next}{i++;if($0~/^tail/){i=0};print $0;print i >> “/root/nnn”;fflush(“”)}’ /root/nnn –
其中/root/data/web.log 为监控的文件，/root/nnn为保存读取记录的文件。
而在flume1.7时新增了一个source 的类型为taildir,它可以监控一个目录下的多个文件，并且实现了实时读取记录保存的功能！功能更加强大！ 先看看官网的介绍：
-Taildir Source