一个数据采集处理系统，架构如下：
日志数据 -> flume -> kafka -> Spark Streaming。
flume到kafka的数据处理时间是1秒多；而spark Streaming的数据处理时间是十几毫秒。
flume方面：
flume数量不够：增加日志服务器以增加并行度；
（1）自身：增加内存flume-env.sh 4-6g
-Xmx与-Xms最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁fullgc。
（2）找朋友：多个目录，多个spooling directory source同时采集
（3）taildir source的batchsize修改为合适的值
( 4 ) flume要读取文件夹如果文件太多，要按最新或最早顺序读取时，会很影响速度。
# batchsize是每次处理的数据条数越高，处理的数据越多，延迟越高。
kafka数据积压的问题，主要的解决办法是：
（1）增加Kafka对应的分区数(比如：期望处理数据的总吞吐量是100M/s。但是实际最多每个分区的生产能力和消费能力的最小值是20M/s，那么我们就需要设置5个或者6个分区)，2）要求下一级消费者配套增加CPU核数，动态增加Kafka服务器集群。
（2）kafka ack设成0(ack有0有1有-1。0的可靠性最差，但是速度最快)
注：ack有3个可选值，分别是1，0，-1。
ack=1，简单来说就是，producer只要收到一个分区副本成功写入的通知就认为推送消息成功了。这个副本必须是leader副本。只有leader副本成功写入了，producer才会认为消息发送成功。
ack=0，简单来说就是，producer发送一次就不再发送了，不管是否发送成功。
ack=-1，简单来说就是，producer只有收到分区内所有副本的成功写入的通知才认为推送消息成功了。
（3） a1.channels.c1.type = memory memory类型可能会丢失数据，但是速度最快。