消息队列的深入理解！

目录

1.消息队列技术选型

2.不用 MQ 系统耦合场景

3.使用 MQ 系统解耦场景

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

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

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

7.使用 MQ 进行削峰的场景

8.Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点

9.消息队列高可用

10.leader和follower的同步机制：

11.消息队列重复数据

12.Kafka 消费端可能出现的重复消费问题

13.保证 MQ 重复消费幂等性

14.保证 MQ 消息不丢

15.RabbitMQ可能存在的数据丢失问题

16.Kafka 可能存在的数据丢失问题

17.消息队列顺序性

18.RabbitMQ 消息顺序错乱

19.RabbitMQ 如何保证消息顺序性

20.Kafka 消息顺序错乱

21.Kafka 保证消息顺序性

22.消息队列延迟以及过期失效

23.快速处理积压的消息

24.如何设计消息队列中间件架构

---

1.消息队列技术选型

解决的问题：

• 解耦

• 异步

• 削峰

2.不用 MQ 系统耦合场景

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

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

3.使用 MQ 系统解耦场景

1. 维护这个代码，不需要考虑人家是否调用成功，失败超时

2. 如果新系统需要数据，直接从 MQ 里消费即可，如果某个系统不需要这条数据就取消对 MQ 消息的消费即可。

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

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

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

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