拓扑结构：
启动两个agent，就是两个flume的任务，可以在同一台机器，也可以在另一台机器。后台服务器和大数据集群不在一块，
数据落在java后台服务器上面，那flume装在哪呢？
装一个在大数据集群机器上，肯定不能读取后台服务器磁盘上的文件。
A机器不能直接读B机器磁盘的文件，必须通过端口网络通信，让他传输过来，假如在后台服务器和大数据集群上都启动了flume，从原始读数据的后台服务器，agent一定放在后台这里，因为跨机器不能直接读取别人磁盘的内容。只能把人家的数据读出来之后，写到某一个端口之后，再去读取。这个是OK的。
但是远程直接把人家的磁盘数据读取过来，这是监控不了的。taildir和exec都可以读文件，文件的地址是不能写别人机器的地址。只能写自己的。
复制和多路复用：
想将采集的数据既发给JDFS。又想发给logger,就要使用副本机制。
一个channel多个sink，这就是sink组。
不使用sink组，直接使用阿波罗sink,一个channel，一个hdfs sink 给数据给hdfs
这样单个sink的压力会很大。使用三个sink的轮询的方式,让三个sink去写数据到hdfs.
负载均衡只要解决单台机器压力过大的问题，同时解决古惑仔那个故障转移的问题。
生产环境主要用负载均衡。
flume存在单点故障的问题。
两个人去读原始数据去读数据，是备份的关系，做不到你不工作，我工作的情况。
聚合：用的很多。
多个源头，不一样的数据，最后的数据都要写到hdfs上去。同时上千个机器去访问hdfs不好，肯定是希望某一台机器去访问hdfs。
生产环境中，后台服务器肯定很多台，他们的数据不是副本关系，多个后台服务器处理同一套业务，但是，任何一台都不可能说同时处理那么多用户的请求，这时候就需要负载均衡，处理的业务，用户请求来了，到底谁来处理呢？前面有个软件层面的负载均衡，将所有请求分别发到不同服务器，每一台服务器上都会产生不同的日志文件，但是最后需要汇总所有的日志。所以，需要将这些服务器做一下聚合，这么多数据写给一个机器，压力太大了。
前面有100台，后面又5台汇总，之后就是这5台服务器操作hdfs
汇总方式1：
三个avro sink发往一个avro source
都发往一个端口44444
汇总方式2：
三个avro sink发往不同的avro source
每个avro sink发往不同的端口。这个也可以，第二层avro source必须要有三个source,
三个source对应一个channel，最后发往hdfs
