消息队列问题

消息队列的使用场景？

消息队列主要有三大使用场景，分别是异步、流量削峰和应用解耦。另外还包含日志和消息通讯。

异步处理：相比于传统的串行、并行方式，提高了系统吞吐量。

流量削峰：可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。

应用解耦：系统间通过消息通信，不用关心其他系统的处理。

日志处理：解决大量日志传输。

消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。

消息队列有什么优缺点？

优点：消息队列可以异步处理、流量削峰、应用解耦、日志处理、消息通讯

缺点：

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来是A系统调用BCD三个系统的接口就好，ABCD四个系统好好的，加个MQ进来，万一MQ挂了整个系统崩溃了。

系统复杂性提高：硬生生加个MQ，无法保证消息队列没有重复消费，怎么处理信息丢失的情况？怎么保证消息传递的顺序邢？

一致性问题：A系统处理完了直接返回成功，人都以为你这个请求就成功了；但是问 题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你 这数据就不一致了。

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？

MQ如何保证消息的高可靠性？

MQ如何保证消息不被重复消费？

消息重复的原因有两个：1.生产时消息重复，2.消费时消息重复。

生产时消息重复

由于生产者发送消息给MQ，在MQ确认的时候出现了网络波动，生产者没有收到确认，实 际上MQ已经接收到了消息。这时候生产者就会重新发送一遍这条消息。

生产者中如果消息未被确认，或确认失败，我们可以使用定时任务+（redis/db）来进行消 息重试。

消费时消息重复

消费者消费成功后，再给MQ确认的时候出现了网络波动，MQ没有接收到确认，为了保证 消息被消费，MQ就会继续给消费者投递之前的消息。这时候消费者就接收到了两条一样的 消息。由于重复消息是由于网络原因造成的，因此不可避免重复消息。但是我们需要 保证消息的幂等性。