为什么使用消息队列？

解耦、异步、削峰。

解耦：系统间耦合比较严重，一个模块调用了多个模块，互相之间的调用比较复杂。如果某一个依赖大面积报错或者挂掉，维护特别麻烦。而且对实时响应没有特别高的要求。

异步：串行化请求会导致一个请求响应时间会很长，如果有一个请求出错，整个响应可能都会挂掉。

削峰：业务高峰期并发请求太多，系统压力过大，写入消息队列后，在并发下来之后处理，性价比极高。

消息队列有什么优缺点？

优点：

解耦、异步、削峰

缺点：

1.增加了消息队列系统可用性会降低(需要额外维护消息队列)

2.系统复杂度会提高(比如消息可靠性传输、避免重复消费、丢消息怎么处理等)

3.一致性问题(调用多个系统，其中某一个系统处理失败了会导致数据不一致)

常用的消息队列有哪些，他们有什么区别？

特性

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 功能，在大数据领域的实时计算以及日志采集被大规模使用

ActiveMQ：之前很火，现在社区不活跃、更新很慢、不太建议使用。

RabbitMQ：开源项目，使用范围很广，社区活跃，适合中小型公司；erlang语言不太好改造。

RocketMQ：阿里开发出来的，可靠性比较强，适合有开发团队专门维护的公司使用。

Kafka：大数据领域实时计算、日志采集等非常适用，几乎是业内标准。