一、消息队列的作用和选型

消息队列的作用

1. 异步处理：用户秒杀成功后可以立刻给用户返回响应，然后把请求的数据放入消息队列中，由消息队列异步地进行后续生成订单、短信通知等操作。
2. 流量控制（削峰）：秒杀开始后，当短时间内大量的秒杀请求到达网关时，不会直接冲击到后端的秒杀服务，而是先堆积在消息队列中，后端服务按照自己的最大处理能力，从消息队列中处理请求。比如采用令牌桶的方式实现：单位时间内只发放固定数量的令牌到令牌桶中，服务在处理请求前必须先从令牌桶中拿出一个令牌才能执行，如果令牌桶中没有令牌，则拒绝请求。这样就保证了单位时间内，能处理的请求不超过发放令牌的数量，于是起到了流量控制的作用。
3. 服务解耦：A 系统通过接口调用发送数据到 B、C、D 三个系统。如果 C 系统不需要数据了，同时又多了个 E 系统也要 A 系统发送的数据，那么 A 系统的维护成本就很高，而且 A 系统要时刻考虑 B、C、D、E 四个系统如果出现故障该怎么办？ 使用消息队列就可以解决这个问题，也就是 A 系统不直接调用其他四个系统的接口了，它只负责生产数据发送到 MQ 中，然后哪个系统需要数据就自己去 MQ 中消费。这样就实现了 A 系统跟其他系统的解耦。

消息队列的选型

1. RocketMQ：基于 Java 语言开发，贡献者大多数是中国人，源代码相对容易读一点，中文社区活跃，方便解决实际碰到的一些问题。每秒钟能处理几十万条消息，比 RabbitMQ 高了一个数量级。而且能做到毫秒级的响应，如果很在意响应时延，那应该选择 RocketMQ，它的低延迟和稳定性非常适合在线业务的场景，比如在交易系统中用消息队列传递订单。
2. Kafka：基于 Scala 和 Java 语言开发。每秒钟也能处理几十万条消息，与周边生态系统的兼容性是最好的，尤其在大数据和流计算领域，几乎都支持Kafka。它的响应时延比较高，当客户端发送一条消息时，Kafka 并不会立即发送出去，而是攒一批了再发送，所以 Kafka 不太适合在线业务的场景。如果是去处理海量的消息，比如收集日志、监控信息等，那么 Kafka 是最合适的消息队列。
3. 如果对消息队列的性能没有很高的要求，只需要开箱即用就好，可以选择 RabbitMQ。