MQ知识梳理

常见MQ有哪几种？分别适用什么场景？

常见的有ActiveMQ，RabbitMQ，RocketMQ，Kafka

ActiveMQ比较成熟，功能多，但也比较老，各方面都不突出，目前已很少使用

RabbitMQ性能高，功能多，吞度量万级，有开源活跃的社区，但由于是erLang语言开发，不适合企业自己搞扩展，是目前中小型企业的不二选择。

RocketMQ性能高（但比RabbitMQ差），功能多，吞吐量10万级，阿里大量应用，java语言编写适合企业自己搞扩展，适合吞吐量大，技术实力强有自己中间件团队的大中型企业

Kafka性能高（但比RabbitMQ差），功能最简单，但吞吐量100万级别，在大数据的实时计算、日志采集等场景已成业界标准，社区活跃度高

参考链接：几种mq的对比_佛山靓仔的博客-CSDN博客_mq 对比

RabbitMQ如何保证消息不丢失？

消息的传递如图

因此消息的丢失和处理也分三种情况，：

1.生产者发出消息，rabbitMQ未接收到。此情况有两种解决方案。

（1）是开启rabbitMQ事务，如果未成功传递给rabbitMQ生产者则会抛异常，属于同步机制

（2）是开启commit机制，rabbitMQ成功接收到消息后会回调生产者的ack接口，一段时间未检测到有回调ack接口则自动调nack接口，属于异步机制。

2.rabbitMQ成功接收消息但未发送给消费者就宕机了。

这种情况需要开启rabbitMQ持久化，以便在重启后恢复消息，这里需要注意下消息队列queue和消息message是分别配置持久化的。需要同时开启两处配置

3.rabbitMQ发出，但消费者未接收到消息

关闭rabbitMQ的自动ack机制即可。消息丢失则不会获取消费成功的ack，则rabbltMQ会重试

RabbitMQ如何保证不重复消费？

可根据业务逻辑分别处理

1.业务逻辑为写库，消息体不含唯一键：将入库后数据的唯一键写入redis，消费前校验重复

2.业务逻辑为写nosql库：不处理，就让他覆盖即可（业务逻辑为更新库也一样）

3.万能方案是将消息传递过来就带唯一键，将这个唯一键写redis中，消费前校验重复