使用消息队列目的
- 通过异步处理提高系统性能（减少响应所需时间）
- 削峰/限流
- 降低系统耦合性
- 顺序保证
- 数据流处理
- 延迟处理
使用消息队列弊端
- 系统可用性降低
- 系统复杂性提高
- 一致性问题
选型对比
Redis
Redis 实现 MQ 主要有三种方案：（1）List 结构；（2）Pub/Sub 模式；（3）Stream 结构。
优点是简单不需要维护MQ服务，但缺点也是简单，并且稳定性和吞吐量无法比拟。
Redis官网：https://redis.io/docs/latest/develop/data-types/streams
ActiveMQ
已经不是最优解，不做过多研究和探讨。
Kafka
Kafka 是 LinkedIn 开源的一个分布式流式处理平台，已经成为 Apache 顶级项目，早期被用来用于处理海量的日志，后面才慢慢发展成了一款功能全面的高性能消息队列。
Kafka 官网：http://kafka.apache.org
RocketMQ
RocketMQ 是阿里开源的一款云原生“消息、事件、流”实时数据处理平台，借鉴了 Kafka，已经成为 Apache 顶级项目。
RocketMQ 官网：https://rocketmq.apache.org
RabbitMQ
RabbitMQ 是采用 Erlang 语言实现 AMQP 的消息中间件，它最初起源于金融系统，用于在分布式系统中存储转发消息。
RabbitMQ 官网：https://www.rabbitmq.com
Pulsar
Pulsar 是下一代云原生分布式消息流平台，最初由 Yahoo 开发 ，已经成为 Apache 顶级项目。
Pulsar 官网：https://pulsar.apache.org
关键标准对比
- 吞吐量：万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。
- 可用性：都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 Kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
- 时效性：RabbitMQ 基于 Erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级，其他几个都是 ms 级。
- 功能支持：Pulsar 的功能更全面，支持多租户、多种消费模式和持久性模式等功能，是下一代云原生分布式消息流平台。
- 消息丢失：ActiveMQ 和 RabbitMQ 丢失的可能性非常低， Kafka、RocketMQ 和 Pulsar 理论上可以做到 0丢失。
总结
- ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用，已经被淘汰了。
- RabbitMQ 在吞吐量方面虽然稍逊于 Kafka、RocketMQ 和 Pulsar，但是由于它基于 Erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 Erlang开发，所以国内很少有公司有实力做 Erlang源码级别的研究和定制。业务场景对并发量要求不是太高（十万级、百万级）首选。
- RocketMQ 和 Pulsar 支持强一致性，对消息一致性要求比较高的场景可以使用。
- RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的 MQ，并且 RocketMQ有阿里巴巴的实际业务场景的实战考验。
- Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 Kafka 最好是支撑较少的 topic数量即可，保证其超高吞吐量。Kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。