国内使用的主流消息队列：
| 消息队列名称 | 主要适用场景 | 服务端核心开发语言 | 主要优点 | 主要缺点 |
|---|---|---|---|---|
| kafka | 应用解耦（异步处理）、流量削锋、日志处理、消息通讯（聊天室等）｜大数据领域应用较多 | Scala | 高性能、低延时、高可用、工具链成熟、生态成熟（监控 运维 管理 方案齐全）、功能较为简单（主要支持简单的MQ功能） | 无法弹性扩容、扩容成本高、消费失败不支持重试 |
| rabbitmq | 应用解耦（异步处理）、流量削锋 | Erlang | mq 性能较好，高并发、吞吐量到万级，MQ功能比较完备、健壮、稳定、易用、跨平台、支持多种语言、文档齐全 | RabbitMQ吞吐量会低一些、需要学习比较复杂的接口和协议，学习和维护成本较高、erlang开发不易于二次开发 |
| acitvemq | 应用解耦（异步处理）、流量削锋 | Java | MQ领域的功能极其完备、有较低的概率丢失数据、基于主从架构实现高可用性、单机吞吐量到万级 | 官方社区现对ActiveMQ 5.x维护越来越少，较少在大规模吞吐的场景中使用 |
| rocketmq | 应用解耦（异步处理）、流量削锋 | Java | 单机吞吐量十万级、非常高的可用性（分布式架构）、经过参数优化配置消息可以做到0丢失、支持10亿级别的消息堆积、MQ功能较为完善、扩展性好 | 支持的客户端语言不多（java和c++）、 没有在 mq 核心中去实现JMS等接口（有些系统要迁移需要修改大量代码） |
| …… | …… | …… | …… | …… |
- Kafka
Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
一般有数据仓库和数据湖的公司，基本针对业务系统会进行数据采集，像是app中的设备信息采集，网站应用中的埋点等等，会采集大量包括用户操作痕迹在内的用户数据，这些数据不可能直接进库（数据仓库），需要进行一层ETL（清洗、转换、抽取）；当然，对于数据湖来说，会直接保存原始采集数据，但是不管，是数据仓库或者数据湖，都不可能直接落库，需要减轻数据入库压力等等，这时候可以通过kafka做一层中间数据传输。
大型公司建议可以选用，如果有日志（设备信息、用户信息等）采集功能，肯定是首选kafka了。
需要注意的是它的MQ功能比较单一。
- RabbitMQ
RabbitMQ 是erlang开发，由于erlang语言本身的并发优势，其性能较好，本身社区活跃度也比较高。但是恰因为是erlang开发，所以它源码看起来比较难懂，不利于做二次开发和维护，主要依赖RabbitMQ的社区来处理开发过程中遇到的bug。
数据量没有那么大的情况下，小公司可以优先选择功能比较完备的RabbitMQ。
- ActiveMQ
ActiveMQ其基本已停止维护，现在选择用ActiveMQ的比较少，早期用ActiveMQ的比较多，所以在一些老项目中比较常见，其MQ功能极其完备，可酌情选择。
- RocketMQ
针对金融互联网领域，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况，这时候可以考虑RocketMQ，这些业务场景在阿里双11已经经历了多次考验，业务有上述并发场景，可以选择RocketMQ。
RoketMQ在稳定性上很高（分布式架构，开发时参考了kafka，吸取了kafka的一些优点，并且针对一些问题进行了改进）。
