消息中间件MQ

1. 为什么使用MQ？

1.1 同步调用

一次用户请求可能会按顺序同步调用多个系统接口，必须所有接口都返回了，才能得到真正执行结果。
总耗时长，在网络环境差的情况下，可能出现接口超时问题

1.2 耦合性高

直接调用一个系统的业务可能涉及间接调用多个子系统的业务。
如果请求时任何一个子系统出现异常，整个请求都会异常，系统不稳定

1.3 请求在某个时刻骤增

在秒杀、双十一等特殊期间用户突增，同一时刻大量请求涌向服务器，可能导致服务器响应变慢或者直接宕机。

2. MQ是如何解决传统开发中的问题的？

2.1 异步调用

为避免响应时间过长，不一定非要等到所有接口都返回之后再返回请求结果。
在调用部分接口之后，已经得到可以响应给用户的结果，这时可以向MQ中生产消息并直接返回结果，其他还未调用的接口会监听并消费MQ中的消息，独立完成剩下的业务。

2.2 解耦

直接调用的系统作为生产者，处理好自己的业务逻辑并向MQ中生产消息之后即可返回结果，其他间接涉及的子系统会监听并消费MQ中的消息，独立完成业务。这样各系统都只依赖于MQ而不会彼此产生依赖。

2.3 削峰

以秒杀场景为例：订单系统自己也可以分为生产者（新增订单）和消费者（订单入库），当生产者收到请求之后直接将其发送到MQ中，消费者会根据自己的速度处理请求，多余的请求会暂时放到MQ中之后处理。

3. MQ会带来哪些新的问题？如何解决？

3.1 重复消费问题

为什么会出现重复消费？

生产者生产了重复消息
消费者确认失败或超时
业务系统主动发起重试

如何解决？
不论是生产者还是消费者导致的重复消息，都可以在消费者处进行解决。
要求消费者在处理业务时，做幂等设计。高并发下保证接口的幂等性
推荐做法：增加一张消息表message，主键是消息的id。在消费者处理业务之前先根据每个消息的id查询该消息是否处理过，如果已经处理过则直接返回，否则继续处理。