为什么选择Canal + Flume + Kafka 架构而不是Canal + Kafka架构？

对于采集MySQL 的Binlog并实时解析，我们知道Canal直接对接的消息队列MQ中就包含Kafka组件，

那么我们为什么不能直接使用Canal + Kafka + SparkStreaming 架构呢？

 

其实上面的问题答案是可以的。

• Canal负责采集

• Kafka负责消息传输以及固化

• SparkStreaming使用Spark引擎解析日志并提取有用的价值。

 

那么我们为什么要使用 Canal + Flume + Kafka 架构，而不是Canal  + Kafka架构？

原因就在于扩展性上面，我们知道 Canal 只是模拟 MySQL 中的 Slave 备份库，“骗来的”日志，

那么我们在业务方面如果有其他的数据源 Oracle, CSV，PostgreSQL，等等需要采集的时候，

我们得去寻找Yugong, 等等类似于Canal一样的能收集到对应数据库或者数据源组件，这个时候我们不建议设计多套架构

• AAAA + Kafka +  ...

• BBBB + Kafka + …

• CCCC + RocketMQ + …

因此我们为了统一数据源，我们使用Flume。

Flume是一个分布式，可靠的，易用的，可以将不同源的日志进行，收集，汇总，或者存储的中间件。

所以这个问题就解决了上面提到的架构问题。