DataPipeline选择MQ模式的理由

DataPipeline选择MQ模式，主要有几点考虑：

第一，在我们产品应用中有一个非常常见的场景：要做数据的一对多分发。数据要进行一次读取，然后分发到各种不同的目的地，这是一个非常适合消息队列使用的分发模型。

第二，有时会对一次读取的数据加不同的处理逻辑，我们希望这种处理不要重新对源端产生一次读取。所以在多数情况下，都需将数据先读到消息队列，然后再配置相应的处理逻辑。

第三，Kafka Connect就是基于MQ模式的，它有大量的开源连接器。基于Kafka Connect框架，我们可以重用这些连接器，节省研发的投入。

第四，当你把数据抽取跟写入目的地，从处理逻辑中独立出来之后，便可以提供更强大的集成能力。因为你可以在消息队列上集成更多的处理逻辑，而无需考虑重新写整个Job。

相应而言，如果你选择将MQ作为所有JOB的传输通道，就必须要克服几个缺点：

第一，所有数据的吞吐都经过MQ，所以MQ会成为一个吞吐瓶颈。

第二，因为是一个完全的流式架构，所以针对批量同步，你需要引入一些边界消息来实现一些批量控制。

第三，Kafka是一个有持久化能力的消息队列，这意味着数据留存是有极限的。比如，你将源端的读到Kafka Topic里面，Topic不会无限的大，有可能会造成数据容量超限，导致一些数据丢失。

第四，当批量同步在中间因为某种原因被打断，无法做续传时，你需要进行重传。在重传过程中，首先要将数据进行清理，如果基于消息队列模式，清理过程就会带来额外的工作。你会面临两个困境：要么清空原有的消息队列，要么你创造新的消息队列。这肯定不如像直接使用一些批量同步框架那样来的直接。