9.ActiveMQ理论

一、首先说下什么是消息队列？

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。