消息队列初步

1、使用场景

异步（秒杀系统）
秒杀操作一般分为多个步骤
如所库存，生成订单，发送短信通知等
锁库存后就丢进消息队列中，后面可以对接各种异步处理
流量控制
在网关和后端服务之间增加消息队列
此处运维人员可以水平扩容后端服务和消息队列
同时无法处理的请求，可以超时关闭
或者使用令牌桶机制
在知道请求量的情况下，令牌桶机制实现简单，redis也可以实现令牌桶机制，或者自己实现一个令牌桶服务
解耦合
实现应用与应用之间的解耦
比如原来的短信通知直接对接短信平台
加入消息队列后服务端和短信平台之间不相互影响

2、不足

增加了系统复杂度
增加了处理链路，可能会使时间延长 一般生产者到消费者之间的数据时延是5ms，如果有处理逻辑可达到1s
可能会有消息丢失

3、选型

作为一款及格的消息队列产品，必须具备的几个特性包括：

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

RabbitMQ
开源
轻量级开箱即用
生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块支持灵活的路由配置
缺点
消息堆积影响性能

RocketMQ
java开发
国产中文社区
对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，如果你的应用场景很在意响应时延，那应该选择使用 RocketMQ
RocketMQ 的性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息
缺点
在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹

Kafka
设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。
Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka
但是 Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。

总结
如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。

如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。