Flume 核心组件笔记
通常情况下 提起Flume 大家都会很自然的想到 Source Channel Sink 这三个 Component，但是 个人觉得 要是想要更好的理解和需要Flume 还至少需要这几个 Component：ChannelProcesser SinkProcesser。
笔者就个人对Flume的认知 画了这个简化图
这里 对Flume的该图简单做一下笔记
最核心的数据流动 自然是：由Source生产数据至Channel，再由Sink将数据从Channel中消费。
ChannelProcesser
ChannelProcesser 主要是由 一下两部分组成 - InterceptorChain & ChannelSelector
Interceptor
Flume对 "调整数据信息" 的操作 提供了插件式的开放，并提供了一些常用的实现。
是的 这种接口就是 – Interceptor。如：HostInterceptor，TimestampInterceptor，StaticInterceptor … 等。
它是为了处理这样需求：
- 如 分布式服务产生的日志，在通过Flume进行采集汇聚之后，需要按照采集主机进行分类（如异常日志，需要明确知道异常所在的机器） – 这时 就需要在采集日志中携带主机信息
- 通过链式的FlumeNG对日志进行采集时，可能会因为各种原因导致日志流延迟，这时 需要定位延迟产生的机器机及时间 – 这时 就需要在采集日志中携带采集时间信息
- 等…
ChannelSelector
想想一下这样的需求：
- 需要对采集的Log4J日志 进行分类处理，按照日志级别进行分类（ERROR，INFO，…）
- 有多处都需要使用到这部分的采集数据，即服务A中需要消费这部分数据，服务B也是一样
Flume对 "对Source中的数据 需要按照特定规则进行分类处理" 的操作 提供了支持，并提供了两种实现 – MultiplexingChannelSelector，ReplicatingChannelSelector。
是的 这种接口就是 – ChannelSelector。
MultiplexingChannelSelector 会对Event进行这样的分流：按照Event.header进行匹配，并对匹配上的Event设定required和optional两种Channel；如果匹配不上，并将该Event分流至default指定的Channel中。
相对于MultiplexingChannelSelector的分流功能 ReplicatingChannelSelector则相对比较简单的做了复制操作。
SinkProcesser
生产环境，需要做到的必不可少的一个保障就是 – 高可用性。很难想象 对于这样的采集服务，如果在Sink出去时由于Sink端的服务不可用（Sink端可能是下一个Flume，或者其他） 从而导致了整个数据流中断 会带来什么样的直接影响。
Flume针对这样的需求 也是提供了三种实现：DefaultSinkProcesser，FailoverSinkProcesser，LoadBalancingSinkProcesser。
FailoverSinkProcesser，LoadBalancingSinkProcesser中 都是包含了一个sinks，从中可以看出，这两个SinkProcesser 对外提供了一个SinkGroup的概念，并对外提供一个集体性的服务，正如它们的命名一样Failover，LoadBalancing。
Flume 中的 Runner
在Flume的以上组件中，会发现 所有的组件都只是提供 do 的逻辑，并不包含 while 的逻辑。而真正的 while 逻辑正在包含在 SourceRunner 和 SinkRunner 中。
SourceRunner
对于SourceRunner，Flume对其分了两大类
- Pollable – 即 主动式的while模型，并获取数据，如：KafkaSource，TaildirSource
- EventDriven – 则是另一种，即 监听式的事件驱动模型，如：AvroSource，ThriftSource
SinkRunner
相对来说 SinkRunner 就简单了，因为它就是负责 主动的 循环 拉去Channel中的数据，所以它只有Pollable这种模型。
