一、首先说下什么是消息队列？
1.消息队列是在消息的传输过程中保存消息的容器。
二、为什么要用到消息队列？
主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达 MySQL ，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。
三、消息队列都分为哪几种？
1. ActiveMQ/ApolloMQ
优点：老牌的消息队列，使用Java语言编写。对JMS支持最好，采用多线程并发，资源消耗比较大。如果你的主语言是Java，可以重点考虑。
缺点：由于历史悠久，历史包袱较多，版本更新很缓慢。集群模式需要依赖Zookeeper实现。最新架构的产品被命名为Apollo，号称下一代ActiveMQ，目前案例较少。
2. RocketMQ/Kafka
优点：专为海量消息传递打造，主张使用拉模式，天然的集群、HA、负载均衡支持。话说还是那句话，适合不适合看你有没有那么大的量。
缺点：所谓鱼和熊掌不可兼得，放弃了一些消息中间件的灵活性，使用的场景较窄，需关注你的业务模式是否契合，否则山寨变相使用很别扭。除此之外，RocketMQ没有.NET下的客户端可用。RocketMQ身出名门，但使用者不多，生态较小，毕竟消息量能达到这种体量的公司不多，你也可以直接去购买阿里云的消息服务。Kafka生态完善，其代码是用Scala语言写成，可靠性比RocketMQ低一些。
3. RabbitMQ
优点：生态丰富，使用者众，有很多人在前面踩坑。AMQP协议的领导实现，支持多种场景。淘宝的MySQL集群内部有使用它进行通讯，OpenStack开源云平台的通信组件，最先在金融行业得到运用。
缺点：Erlang代码你Hold得住不? 虽然Erlang是天然集群化的，但RabbitMQ在高可用方面做起来还不是特别得心应手，别相信广告。
背景知识点
JMS：Java Message Service Java消息服务
消息队列：消息的传输过程中保存消息的容器
消息队列主要特点：异步处理
主要目的：减少请求响应时间和解耦
使用场景：将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列
ActiceMQ相关概念
1.Destination
目的地，JMS Provider（消息中间件）维护，用于对Message进行管理的对象。
MessageProducer需要指定Destination才能发送消息，MessageConsumer需要指定Destination才能接收消息。
2.Producer
消息生成者（客户端，生成消息），负责发送Message到目的地。应用接口为MessageProducer
3.Consumer【Receiver】
消息消费者（处理消息），负责从目的地中消费【处理|监听|订阅】Message。应用接口为MessageConsumer
4.Message
消息（Message），消息封装一次通信的内容。常见类型有：StreamMessage、BytesMessage、TextMessage、ObjectMessage、MapMessage。
5.ConnectionFactory
链接工厂, 用于创建链接的工厂类型。 注意，不能和 JDBC 中的 ConnectionFactory 混
淆。
6.Connection
链接. 用于建立访问 ActiveMQ 连接的类型, 由链接工厂创建. 注意，不能和 JDBC 中的
Connection 混淆。
7.Session
会话, 一次持久有效有状态的访问. 由链接创建. 是具体操作消息的基础支撑。
8.Queue&Topic
Queue是队列目的地，Topic是主题目的地。都是Destination的子接口。
Queue特点：队列中的消息，默认只能有唯一的一个消费者处理。
Topic特点：主题中的消息，会发送给所有的消费者同时处理。只有在消息可以重复处理的业务场景中可使用。
9.PTP
Point to Point。点对点消息模型，就是基于Queue实现的消息处理方式。
10.PUB&SUB
Publish&Subscribe。消息的发布/订阅模型。是基于Topic实现的消息处理方式。
PTP 和 PUB/SUB对比
地址的 sub 能够接收到消息；如果没
有 sub 在监听，该 topic 就丢失了。 |
| 消息发布接受策略 | 一对一的消息发布接受策略，一个sender发送的消息，只能有一个receiver接受。receiver接受完后，通知mq服务器已接受，mq服务器对queue里的消息采取删除或其他操作 | 一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器 |
安全认证
暂时未用到，此处有待添加
持久化
1.kahadb方式
是 ActiveMQ 默认的持久化策略。kahadb 是一个文件型数据库。是使用内存+文件保证
数据的持久化的。kahadb 可以限制每个数据文件的大小。不代表总计数据容量。
特性是：1、日志形式存储消息；2、消息索引以 B-Tree 结构存储，可以快速更新；3、
完全支持 JMS 事务；4、支持多种恢复机制；
2.AMQ方式（过时不推荐）
3.JDBC持久化
下述文件为 activemq.xml 配置文件部分内容。不要完全复制。
首先定义一个 mysql-ds 的 MySQL 数据源，然后在 persistenceAdapter 节点中配置
jdbcPersistenceAdapter 并且引用刚才定义的数据源。
dataSource 指定持久化数据库的 bean，createTablesOnStartup 是否在启动的时候创建数
据表，默认值是 true，这样每次启动都会去创建数据表了，一般是第一次启动的时候设置为
true，之后改成 false。
相关表介绍：
activemq_msgs
用于存储消息，Queue 和 Topic 都存储在这个表中：
ID：自增的数据库主键
CONTAINER：消息的 Destination
MSGID_PROD：消息发送者客户端的主键
MSG_SEQ：是发送消息的顺序，MSGID_PROD+MSG_SEQ 可以组成 JMS 的 MessageID
EXPIRATION：消息的过期时间，存储的是从 1970-01-01 到现在的毫秒数
MSG：消息本体的 Java 序列化对象的二进制数据
PRIORITY：优先级，从 0-9，数值越大优先级越高
activemq_acks
用于存储订阅关系。如果是持久化 Topic，订阅者和服务器的订阅关系在这个表保存：
主要的数据库字段如下：
CONTAINER：消息的 Destination
SUB_DEST：如果是使用 Static 集群，这个字段会有集群其他系统的信息
CLIENT_ID：每个订阅者都必须有一个唯一的客户端 ID 用以区分
SUB_NAME：订阅者名称
SELECTOR：选择器，可以选择只消费满足条件的消息。条件可以用自定义属性实现，
可支持多属性 AND 和 OR 操作
LAST_ACKED_ID：记录消费过的消息的 ID。
activemq_lock
在集群环境中才有用，只有一个 Broker 可以获得消息，称为 Master Broker，其他的只能作为备份等待 Master Broker 不可用，才可能成为下一个 Master Broker。这个表用于记录哪个 Broker 是当前的 Master Broker。只有在消息必须保证有效，且绝对不能丢失的时候。使用 JDBC 存储策略。如果消息可以容忍丢失，或使用集群/主备模式保证数据安全的时候，建议使用 levelDB或 Kahadb。
————————————————
版权声明：本文为CSDN博主「MaybeJ」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39905910/article/details/86447368