【消息队列】： Kafka、ActiveMQ、RabbitMQ、RocketMQ相关总结

前言

在写Flink任务的过程中，流计算需要支持去Kafka，RabbitMQ，ActiveMQ消费数据。这里咋一看这三个不都是消息队列么，为啥要搞三个呢？何不把它们统一起来。因此处于好奇，就对消息队列的相关框架做了一番认识。

本文涉及到的内容：

1. 为什么使用消息队列？
2. 消息队列有什么优点和缺点？
3. Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？

1.为什么要使用消息队列

先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。

解耦

看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…

在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！

如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。

这里我们可以回顾一下自己曾经负责的系统中