为什么需要消息队列
1.异步处理：短时间接收到海量请求时，如果同步处理可能会导致响应时间过长，如果异步处理可以就更快地返回结果提供系统总体性能
2.流量控制：请求过多可能会压挂后端服务器，如果使用消息队列，网关将请求放入消息队列中，后端服务根据自己的能力不断地从消息队列消费请求，可以达到削峰填谷的作用。（如果将请求放入消息队列会造成请求调用链过长，所以可以使用令牌桶的方式，每次请求都从令牌桶中取出令牌后调用后端服务器，如果没有取到令牌则返回失败）
3.服务解耦：当后端服务提供多个接口为其他服务时，可能会因为其他服务的变化而变化接口，所以后端服务可以使用消息队列将数据放入其中，达到服务之间的解耦
消息队列产品
RabbitMQ：
RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用。RabbitMQ在生产者和队列之间存在着一个exchange模块，这个模块的作用可以根据配置的路由规则将消息分发到不同的队列，RabbitMQ 对消息堆积的支持并不好，大概me秒最高能处理几万到十几万条消息。如果对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议使用 RabbitMQ。
RocketMQ
RocketMQ对在线业务的响应时延做了很多优化，并且每秒钟能够处理几十万条消息，一般在线业务或者交易系统一般都使用RocketMQ
Kafka
Kafka对同步首发消息的响应时延较长，一般不太适合处理在线业务，而是适合处理日志，监控信息等海量数据。
确保消息队列的可靠性
生产阶段：在发送消息消息后判断返回值，如果是异步发送，则需要判断回调结果
存储阶段：消息队列在收到消息并写入磁盘后再返回结果，如果是多节点，则等待至少两个节点收到消息后再返回确认
消费阶段：消费端在收到消息并处理完业务后再向消息队列返回确认即可保证消息不会因为消息队列认为已经消费而将消息丢失。
无论是broker或者consumer都可能会存在消息重复，怎么解决
MQTT协议中，存在三种消息队列的服务质量：At most once，最多一次，不保证消息一定会收到；At least once:至少一次，不保证消息重复；Exactly once，恰好一次，不允许丢失也不允许重复。大部分的消息队列都只保证了At least once，即不保证消息重复。
解决方法：
1.业务方通过幂等性设计保证不会消费重复消息；
a.利用数据库的唯一性约束
b.为更新数据设置前提条件，如果满足第一次消费的条件则消费，消费后条件变化无法满足第一次消费的条件
c.记录全局唯一ID作为已经消费的消息
优化避免消息积压
大部分的性能问题都出现在消费端
1.水平扩容消费者可以解决消费能力跟不上生产能力的问题
2.可以先将消息取出后放入内存队列并返回成功给消息队列
