一、为什么使用消息队列？
从三个层面通过公司具体业务场景来回答
1. 异步
比如说，我之前在公司做的一个系统叫“跟踪提醒平台”，是一个公共的平台，可以给客户或者业务人员推送消息，如电话语音、短信、邮件、APP内消息和微信消息等。其他系统对接我们，需要在我们系统这边配置提醒规则和对象。然后他们会推送MQ消息，我们去消费处理。
为什么使用MQ呢？如果不用MQ的话，只能通过调用接口的方式。我们考虑到调用接口会有2个缺点:
一是会阻塞，像我们系统提醒业务处理过程通常要1-2秒，如果一下来了太多请求，可能是处理不过来的，后面的请求只能一直等甚至超时；而MQ支持消息堆积，很好解决了这个问题。
二是调用失败无法自动重试，MQ可以很容易实现失败重试。
2. 削峰
削峰跟前面说的异步很像，比如有些系统通常是晚上2点跑规则然后去给我们推送消息，让我们帮他们提醒客户或业务人员。
突然大量请求过来，短时间内我们可以处理不过来的，所以需要消息堆积。MQ可以帮我们存储消息，而且对接方对也不要求实时性， 所以我们可以慢慢消费处理，很舒服。
3. 解耦
比如客户报案后，我们处理报案信息生成案件号等逻辑执行完后，需要把报案信息推送给A、B、C这3个其他的系统。
如果用调用接口方式，调用三次接口，也不是不可以实现。但是如果后期B系统说你不需要推送给我了。我这边是不是需要删除掉推送给B的代码，这就是代码耦合了。
通过MQ可以解决这个问题，我往指定的TOPIC:TAG里推送消息，然后A、B、C三个项目都去订阅TOPIC:TAG，推送方式可以广播模式。如果B系统不需要报案信息，可以去取消订阅这个TOPIC:TAG，或者他们自己修改业务代码，而我这边是不需要修改的，美滋滋。
二、消息队列的优缺点
优点上面说了，有利于 异步、削峰和解耦
缺点：
1. MQ让系统更复杂，开发难度和成本上身，而且如果MQ挂了，那个功能就不可用了
2. 消息没有返回值(只知道消息是发送成功了)，如果需要返回结果，需要再通过MQ回传给对方一条信息，复杂度增加
3. 可能会出险消息丢失的或者重复消费的情况，调用方不感知
三、Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
1. ActiveMQ：比较老，功能比较强，但是现在用的人很少，社区也不活跃。建议放弃
2. RabbitMQ: erlang语言开发的，对我们搞Java如果想去深入研究它的不太友好，社区活跃。还是值得信赖的，小公司可以使用
3. RocketMQ: Java语言开发的，阿里开源的捐给Apache了，社区活跃度不如Rabbit，公司有实力的推荐使用
4. Kafka: 吞吐量较高，常用于大数据领域的实时计算、日志采集等场景，社区活跃度高
特性
ActiveMQ
RabbitMQ
RocketMQ
Kafka
单机吞吐量
万级，比 RocketMQ、Kafka 低一个数量级
同 ActiveMQ
10 万级，支撑高吞吐
10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响
topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic
topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性
ms 级
微秒级，这是 RabbitMQ 的一大特点，延迟最低
ms 级
延迟在 ms 级以内
可用性
高，基于主从架构实现高可用
同 ActiveMQ
非常高，分布式架构
非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性
有较低的概率丢失数据
基本不丢
经过参数优化配置，可以做到 0 丢失
同 RocketMQ
功能支持
MQ 领域的功能极其完备
基于 erlang 开发，并发能力很强，性能极好，延时很低
MQ 功能较为完善，还是分布式的，扩展性好
功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
