1、选择消息队列MQ

一、为什么需要MQ

1、异步处理

更快的返回结果。
减少等待，实现了步骤之间的并发，提升系统整体性能。

2、流量控制

使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。

秒杀开始后，当短时间内大量的秒杀请求到达网关时，不会直接冲击到后端的秒杀服务，而是先堆积在消息队列中，后端服务按照自己的最大处理能力，从消息队列中消费请求进行处理。
令牌桶：单位时间内只发放固定数量的令牌到令牌桶中，规定服务在处理请求之前必须先从令牌桶中拿出一个令牌，如果令牌桶中没有令牌，则拒绝请求。这样就保证单位时间内，能处理的请求不超过发放令牌的数量，起到了流量控制的作用。
令牌桶可以简单地用一个有固定容量的消息队列加一个“令牌发生器”来实现。网关在收到请求时去令牌队列消费一个令牌，获取到令牌则继续调用后端秒杀服务，如果获取不到令牌则直接返回秒杀失败。

3、服务解耦

二、高性能MQ

消息的可靠传递：确保不丢消息；
Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；
性能：具备足够好的性能，能满足绝大多数场景的性能要求。

1、RabbitMQ

1、轻量级、迅捷。
2、支持非常灵活的路由配置，在生产者和队列之间增加了一个Exchange模块。
问题：
1、对消息堆积的支持不好，大量消息堆积，RabbitMQ性能急剧下降。
2、性能不如其他队列
3、开发语言Erlang小众

2、RocketMQ

不错的性能、稳定性、可靠性。活跃的中文社区。毫秒级响应。几十万/秒
在国际上没那么流行，与生态的集成略逊。

3、Kafka

Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。
超高性能。
问题：
同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。
Kafka 不太适合在线业务场景。

三、选择：

如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。
你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。
如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。