9.ActiveMQ理论

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

1.消息队列是在消息的传输过程当中保存消息的容器。

2、为何要用到消息队列？

主要缘由是因为在高并发环境下，因为来不及同步处理，请求每每会发生堵塞，好比说，大量的insert，update之类的请求同时到达 MySQL ，直接致使无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。经过使用消息队列，咱们能够异步处理请求，从而缓解系统的压力。

3、消息队列都分为哪几种？

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 能够限制每一个数据文件的大小。不表明总计数据容量。

 

 

特性是：一、日志形式存储消息；二、消息索引以 B-Tree 结构存储，能够快速更新；三、
彻底支持 JMS 事务；四、支持多种恢复机制；

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