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這種模型。