MQ概述

消息队列的好处？
解耦、异步、削峰
不用MQ的系统耦合场景
发送数据的模块A严重跟别的模块耦合起来，A模块产生了比较关键的数据，很多模块都需要这个A模块将数据发送来，如果新的模块又需要A模块的数据，那么A模块就要修改代码，把数据发送到新的模块，如果某个模块又不需要A模块的数据，那么A模块就又要修改自己的代码，不向不需要数据的模块发送数据

使用MQ的系统耦合场景
通过一个MQ，发布和订阅消息的这么一个模型，Pub/Sub模型，需要发送数据的模块就和其他的模块彻底解耦

不用MQ的同步高延迟场景

使用MQ进行异步化优化的接口调用

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

使用MQ来解决削峰
在高峰期的时候，比如mysql每秒只能处理2000个请求，但是高峰期每秒有5000个请求，那么我就就使用MQ，每秒向MQ中写入5000个请求，然后mysql再从MQ中慢慢拉，每秒拉取2000个请求，不要超过mysql每秒能处理的数量就行了，保证mysql不会挂掉

MQ存在的一些问题
1.模块系统可用性降低：一旦MQ出问题了，就无法向MQ中发送消息，别的模块也无法消息，整个系统就可能会崩掉
2.系统的复杂性提高：系统要考虑的问题变多了，比如发送来消息没有系统来消费，导致MQ大量数据积压
3.一致性问题：比如A、B、C系统都执行成功，但是D系统没有成功，给用户返回的是成功，但是后台却还差点
activmq、rabbitmq、rocketmq、kafka的优缺点
activmq：社区不活跃，吞吐量万级，源码是java
rabbitmq：根据服务器配置决定吞吐量。也是万级，性能极好，延迟很低，用erlang开发
rocketmq：10万级，源码是java
kafka：功能少，吞吐量超高，适合大数据领域，利于扩展
rabbitmq普通集群原理分析
消费者很多的话可以连接任一节点进行消费

rabbitmq的镜像模式
是高可用的（非分布式）
写入消息去任意节点，他都会把消息分布到别的节点，消费者去任意节点都有queue的完整信息

mq可能会出现重复消费的问题
消费者在准备提交offset的时候，但是消费者进程被重启了，那么此时被消费的offset并没有提交，mq也不知道此条消息被消费了，会继续向消费者发送消息，这就出现了重复消费，可能会在数据库插入两次同样的数据

如何保证mq重复消费的幂等性
每次消费一条数据，就像set里插入或者去比较有没有这条数据，有的话就不处理。或者基于数据库的为唯一键来保证重复的数据不会插入多条。这两种方案都恶意解决mq的重复消费

rabbitmq可能存在消息丢失的问题
1.在生产者发送消息的时候，网络传输过程中把数据弄丢了，或者mq内部出错
2.mq把接受的消息暂存在自己的内存，消费者还没来得及消费就挂了，数据就丢了
3.消费者消费到了消息，还没来得及处理，自己挂了，mq以为消费者处理完了，就不会向消费者发送消息了
解决方法：
生产者：
设置事务或者把channal设置为confirm，一般使用后者，应为事务是同步阻塞，会影响吞吐率，mq如果接受到消息，回调生产者本地接口，通知收到。如果报错，回调生产者本地接口，通知失败，重新发送
mq方面：
创建queue的时候将其设置为持久化
消费者方面：
还没消费完就自动autoAck，我们将autoAck关闭，自己确认已处理完再送送到mq

mq可能出现数据顺序不一致的场景

如何保证mq数据顺序的一致性
如果有多个消费者的话，就给每一个消费者开一个queue队列，这样就能保证数据顺序的一致性

如何解决消息队列的延时以及过期失效问题？消息队列满了怎末处理？有几百万消息持续积压几小时怎么解决？
消费者出故障，造成mq中积攒了几百万数据，如果太多即使消费者恢复了，也得很长时间，我们可以新建partition，再去部署很多个消费者