消息队列是在消息的传输过程中保存消息的容器，包含以下 3 元素：
Producer：消息生产者，负责产生和发送消息到 Broker；
Broker：消息处理中心，负责消息存储、确认、重试等，一般其中会包含多个 Queue；
Consumer：消息消费者，负责
从 Broker 中获取消息，并进行相应处理。
点对点模式：多个生产者可以向同一个消息队列发送消息，一个具体的消息只能由一个消费者消费。
发布/订阅模式：单个消息可以被多个订阅者并发的获取和处理。
应用解耦：消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节。
异步处理：消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息。
流量削锋：当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的”载体”，在下游有能力处理的时候，再进行分发与处理。
日志处理：日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。
消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯，比如实现点对点消息队列，或者聊天室等。
消息广播：如果没有消息队列，每当一个新的业务方接入，我们都要接入一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。
官方社区现在对 ActiveMQ 维护越来越少，较少在大规模吞吐的场景中使用，主要使用 Kafka、RabbitMQ 和 RocketMQ。
优点：
缺点：
Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长；
不支持消息路由，不支持延迟发送，不支持消息重试；
社区更新较慢。
优点：
高吞吐：借鉴 Kafka 的设计，单一队列百万消息的堆积能力；
高伸缩性：灵活的分布式横向扩展部署架构，整体架构其实和 kafka 很像；
高容错性：通过ACK机制，保证消息一定能正常消费；
持久化、可回溯：消息可以持久化到磁盘中，支持消息回溯；
缺点：
不支持消息路由，支持的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟；
社区活跃度一般。
优点：
支持几乎所有最受欢迎的编程语言：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；
支持消息路由：RabbitMQ 可以通过不同的交换器支持不同种类的消息路由；
消息时序：通过延时队列，可以指定消息的延时时间，过期时间TTL等；
支持容错处理：通过交付重试和死信交换器（DLX）来处理消息处理故障；
提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker；
社区活跃度高。
缺点：
Erlang 开发，很难去看懂源码，不利于做二次开发和维护，基本只能依赖于开源社区的快速维护和修复 bug；
RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重；
不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般。
选择rabbitMQ情况，高级灵活的路由规则，需要延迟队列的支持。
RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
语言
kafka使用scala写的，rabbitmq使用erlang写的，rocketMQ使用java写的
