Flume边看源码边扯淡

Flume介绍

Flume是cloudera公司开源的数据收集存储产品,已经是当前系统架构图中的重要一员了,能够提供大量可选的信息收集、过滤、负载均衡转储等功能,在实际工作当中主要面向文件形式的日志文件进行流式读出并通过内部队列以消费的方式写入到对应的服务器端进行二次处理或者直接存储。

PS:没有对Flume进行过代码层面的优化,仅针对实际业务场景和源码分析的介绍,不正之处,望指出。

Flume和Trace系统

Flume是运维使用的一款重要工具,平常开发人员对Flume的使用很少,为了达到解耦的目的,项目中也很少去集成Flume被动的使用Source功能,但是Flume的实现方式以及源码的研究价值远远大于这个工具本身,在之前开发的跟踪系统中就有着天然的相似之处,收集处理消费,不同的是跟踪系统需要处理业务上的各种链路数据模型,而Flume同时能够根据事务提供可靠的服务模式。在Flume使用中,平常使用Zabbix进行监控。

Flume和Log

Flume和Log是一对亲兄弟,最常用的方法是Log直接记录数据到指定的文件,并通过Log输出相对组织过的数据结构数据,这些配置可以通过logback或者log4j等框架提供,在该实例机上面配置并启动Flume实例Agent,通过FileSource的tail -f循环的形式读取信息到Channel,另外一种形式是调用log框架并配置logAppender直接将数据通过log方法写入到Source,这种方式使用EmbededAgent形式加入依赖。

在基于链路分析的系统中log这种点状形式不足以很好地填充整个链路上的时序数据,主要表现在分布式的场合和数据的有序性,但是可以通过ThreadLocal或者MDC类,首先对数据在代码中进行整合后在最终时间输出到日志,分布式场景下定义统一的TraceId,再然后通过自定义收集器或直接使用FlumeSource即可。

Flume和MQ

说起MQ就会想起下面三个对象:

  1. 生产者
  2. 消费者
  3. 队列

这三个对象刚好和Flume中的Source、Sink和Channel匹配起来,这就是典型的生产者消费模式,某种情况下Flume可以充当一个MQ来使用。

接下来看一下Flume分别是如何去设计MQ的三元素的,并且都具备哪些特定的MQ的特性,比如可靠性、多消费、Queue、Topic。

Flume和RPC

说起RPC,可能想到的就是Dubbo,Grpc等Rpc框架,Rpc框架中的重要成员包括:

  1. 客户端
  2. 服务端
  3. 传输协议
  4. 负载均衡

Flume也有自己的Rpc功能用于数据的集中和分发中继模式,那Flume的这些PRC特性主要体现在哪里呢?