目前业务上需要选用合适的消息队列来做数据传输，因此特意调研了一下当下较主流的消息队列的各特点：
消息中间件三要素：生产者、消息、消费者。
衡量标准：生产者、消息、消费者三者的交互。
1.消息路由：消息如何经过消息中间件到达消费者。
2.消息可靠性：
2.1.不允许消息丢失
2.2.允许消息丢失，性能需求大于可靠性
3.消息重放：已经消费过的消息是否能设置某一时间间隔后重新被消费（适用于新系统导入旧数据，防数据丢失）
4.消息堆积：流量高峰期时，消息中间件在高并发投递消息时可能会出现问题，所以把消息暂存在中间件，等流量高峰过去，再投给下游业务
5.消息优先级：
5.1.消息投递顺序和消费顺序一致
5.2.可设置某些消息的消费优先级
6.性能和扩展
6.1.性能：主要指tps、qps以及并发连接数
6.2.扩展：通过添加消费者来提高消费速率、消息中间件的容量上限
| Kafka | RabbitMQ | ActiveMQ | Redis | RocketMQ |
消息回溯 | 支持。无论是否被消费都会保留。可设置策略进行过滤删除(时间或大小) | 不支持，一旦被确认消费就会标记删除 | | 可设置消息过期时间，自动过期 | |
API完整性 | 高 | 高 | 中 | 高 | |
单机吞吐量 | 十万级 | 万级 | 万 | 十万级 | |
部署难度 | 中 | 低 | 低 | 低 | |
消息堆积 | 支持 | 支持(消息堆积数量大的时候，可用性急剧下降) | 支持 | 支持 | |
消息持久化 | 支持 | 支持 | | 支持 | |
多语言支持 | 支持，Java优先 | 语言无关 | 支持，Java优先 | 支持 | |
消息延迟 | 不支持 | 支持 | 支持 | 支持 | |
消费模式 | 拉模式 | 推+拉 | 推+拉 | 拉模式 | |
消息追溯 | 不支持 | 支持(有插件，可进行界面管理) | 支持 | 支持 | |
常用场景 | 日志处理，大数据等 | 金融支付机构 | | 共享Cache,共享session等 | |
| | | | | |
| | | | | |
参考：https://www.jianshu.com/p/2838890f3284
