为啥用mq
个人感觉最主要有两个场景：
1是削峰，对于突然涌进来的流量，可以先简单的记录参数值，后面消费消息慢慢处理这些数据
2是异步 ，对于一些比较耗时的操作，像发邮件或发短信之类的，可以让这些步骤脱离主程序，存到mq里，后续消费处理
3是解耦，服务器之间各种数据需要传递，使用mq十分方便转发数据给各个需要的服务器
如何使用mq
rabbitmq主要三种模式：
1：Direct Exchange (精准查询，生产一对一消费，轮询消费模式)
队列绑定到交换机上，并指定路由键 routing key的名称，然后生产者指定发送哪个交换机上的哪个路由键上，消费者就精确查找到这个路由键进行消费消息。
2.Topic Exchange(模糊查询，生产一对多消费)
队列绑定到交换机上，并指定路由键 routing key的名称，然后生产者安照rabbitmq的模糊匹配规则发送消息，满足模糊匹配规则的消费者就能消费到。
3.Fanout Exchange(范围查询，生产一对多消费)
扇型交换机，这个交换机没有路由键概念，就算你绑了路由键也是无视的。 这个交换机在接收到消息后，会直接转发到绑定到它上面的所有队列。
springboot整合mq还是十分方便的，看实际需求选择哪种模式就好
mq确保消息成功发送问题
有两种方法实现：
1.通过AMQP提供的事务机制实现
2.使用发送者确认模式实现
两者区别：如果事务发送消息失败，然后就停止发送消息了，它只是会报错提示你失败了；而确认模式是通过补发消息方式，直到消息发送到对方确认发送成功了为止。
mq重复消费问题
mq产生重复消费场景可能原因有：
1.消费者消费这条消息的时候，正好执行了业务逻辑代码，马上通知rabbitmq已确认消费的时候，rabbitmq这时候宕机了。然后重新启动rabbitmq的时候，这条消息又被消费了
2.生产者因为网络波动，第一次发送消息的时候没有得到应答，导致生产者又发送了一条相同的消息
从产生的场景来看，mq重复消费的条件也是比较苛刻的。如果是一般业务，重复消息就让它重复消费吧。但对于一些重要业务，比如付款这样的，那就一单也不能重复了。
如何解决：
只能从消费消息那里入手，消费消息的时候保证数据的幂等性(幂等性：多次处理相同消息，最终结果是一致的)
比如付款成功操作，可以通过判断是否是已支付状态来保持幂等
比如创建订单操作，可提前分配订单id给新订单，创建订单的参数mq传过来，消费的时候就可以通过判断订单id是否重复
mq防消息丢失
mq自身可能会丢失消息
比如mq生产者发送了消息，这时候消息还只是在内存中，如果这时候mq宕机，那么内存中的数据就都没了。
解决：设置mq将消息写入磁盘，这样就算mq宕机，mq启动的时候会将未消费的消息重新加载到内存中进行消费
