面试官：消息队列这些我必问

消息队列连环炮

1. 项目里怎么样使用 MQ 的？
2. 为什么要使用消息队列？
3. 消息队列有什么优点和缺点？
4. kafka,activemq,rabbitmq,rocketmq 都有什么去呗？
5. 如何保证消息队列高可用？
6. 如何保证消息不被重复消费？
7. 如何保证消息的可靠性传输？
8. 如何保证消息的顺序性？
9. 写一个消息队列架构设计？

消息队列技术选型

解决的问题：

• 解耦
• 异步
• 削峰

不用 MQ 系统耦合场景

A 系统产生了一个比较关键的数据，很多系统需要 A 系统将数据发过来，强耦合（B,C,D,E 系统可能参数不一样、一会需要一会不需要数据，A 系统要不断修改代码维护）

A 系统还要考虑 B、C、D、E 系统是否挂了，是否访问超时？是否重试？

使用 MQ 系统解耦场景

1. 维护这个代码，不需要考虑人家是否调用成功，失败超时
2. 如果新系统需要数据，直接从 MQ 里消费即可，如果某个系统不需要这条数据就取消对 MQ 消息的消费即可。

总结：通过一个 MQ 的发布订阅消息模型（Pub/Sub）, 系统 A 跟其他系统就彻底解耦了。

不用 MQ 同步高延迟请求场景

一般互联网类的企业，对用户的直接操作，一般要求每个请求都必须在 200ms以内，对用户几乎是无感知的。

使用 MQ 进行异步化之后的接口性能优化

提高高延时接口

没有用 MQ 时高峰期系统被打死的场景

高峰期每秒 5000 个请求，每秒对 MySQL 执行 5000 条 SQL（一般MySQL每秒 2000 个请求差不多了），如果MySQL被打死，然后整个系统就崩溃，用户就没办法使用系统了。但是高峰期过了之后，每秒钟可能就 50 个请求，对整个系统没有任何压力。

使用 MQ 进行削峰的场景

5000 个请求写入到 MQ 里面，系统 A 每秒钟最多只能处理 2000 个请求（MySQL 每秒钟最多处理 2000 个请求），系统 A 从 MQ 里慢慢拉取请求，每秒钟拉取 2000 个请求。MQ，每秒钟 5000 个请求进来，结果只有 2000 个请求出去，结果导致在高峰期（21小时），可能有几十万甚至几百万的请求积压在 MQ 中，这个是正常的，因为过了高峰期之后，每秒钟就 50 个请求，但是系统 A 还是会按照每秒 2000 个该请求的速度去处理。只要高峰期一过，系统 A 就会快速的将积压的消息给解决掉。

算一笔账，每秒积压在 MQ 里消息有 3000 条，一分钟就会积压 18W 条消息，一个小时就会积压 1000 万条消息。等高峰期一过，差不多需要 1 个多小时就可以把 1000W 条积压的消息给处理掉

架构中引入 MQ 后存在的问题

1. 系统可用性降低

MQ 可能挂掉，导致整个系统崩溃

2. 系统复杂性变高

可能发重复消息，导致插入重复数据；消息丢了；消息顺序乱了；系统 B,C,D 挂了，导致 MQ 消息积累