ActiveMQ知识整理+⾯试题
AcitveMQ
⾸先，说起ActiveMQ，就必须先聊聊JMS（Java Message Service）规范，也就是Java消息服务，它定义了Java中访问消息中间件的接⼝的规范。JMS只是接⼝，并没有给予实现，实现JMS接⼝的消息中间件称为 “JMS Provider”，⽬前知名的开源 MOM （Message Oriented Middleware，也就是消息中间件）系统包括Apache的ActiveMQ、RocketMQ、Kafka，以及RabbitMQ，可以说他们都 “基本遵循” 或 “参考” JMS规范，都有⾃⼰的特点和优势。
mq能解决什么问题：
异步：调⽤者⽆需等待
解耦：解决系统之间的耦合调⽤
削峰：抵御洪峰流量，保护核⼼业务
activemq的简单介绍：
activemq有两种模式，⼀种是queue模式，⼀种的topic模式。queue模式的消息默认是持久化的，被消费者消费完就没了，⼀个消息只能被⼀个消费者消费。topic是⼀种主题订阅模式，消费者需要先订阅⼀个topic，然后消息出现了才会发送给订阅者，如果没有订阅者，消息会被丢弃。
五种消息格式
typeMessage、StreamMessage、TextMessage、ObjectMessage、MapMessage
传输协议
activemq⽀持很多种的传输协议，默认是使⽤http协议，可以更改为nio协议提升activemq传输性能
持久化
queue默认是持久化的，topic默认不是
底层实现：
amq message store基于⽂件的存储形式
kahadb 基于索引和⽇志⽂件的存储形式
jdbc 基于数据库的存储
level db基于⽂件的数据库存储
⽬前默认使⽤kahadb
kahadb：
包含四个⽂件： db.data da.do lock
⼤致流程：消息以追加的形式加到db-< number>.log⽂件中，如果⽂件满了，就新建⼀个log⽂件（默认最⼤⼤⼩为32M），同时number + 1。db.data存的是btree索引，指向log⽂件，如果⼀个log⽂件没有引⽤了，就会被归档或者删除
db.data：btree索引，指向log⽂件。维护了⼀个FIFO队列，消息被消费后就出队（被移除）
db.free：表⽰哪些⽂件是空的
lock：表⽰获得的锁的broker
jdbc存储
有三个表，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：订阅者和服务器的关系放在这⾥表⾥
CONTAINER：消息的Destination
SUB_DEST：如果是使⽤Static集，这个字段会有集其他系统的信息
CLIENT_ID：每个订阅者都必须有⼀个唯⼀的客户端ID⽤以区分
SUB_NAME：订阅者名称
SELECTOR：选择器，可以选择只消费满⾜条件的消息。条件可以⽤⾃定义属性实现，可⽀持多属性AND和OR操作
LAST_ACKED_ID：记录消费过的消息的ID。
activemq-lock：获取了锁的broker，集环境下⽣效
LevelDB
⽬前已经被不推荐使⽤的
The main reason is that KahaDB continues to be the main focus where bugs are fixed and not much attention is paid to LevelDB. There seems to be several issues with corruption (especially with replication) so I don’t think it should be a recommended store unless the stability is sorted out. Unfortunately nearly every JIRA reported against LevelDB goes ignored.
⼤概意思是：KahaDB仍然是BUG修复的主要关注点，并且没有对LevelDB给予太多关注。它似乎有⼀些问题（特别是在
replication），所以并不推荐它作为存储⽅式，除⾮稳定性能够得到保证。
没啥了解，以后在补充吧。。。
activemq集环境搭建
⾯试题
activemq有⼏种通信⽅式？
publish(发布)-subscribe(订阅)(发布-订阅⽅式)
发布/订阅⽅式⽤于多接收客户端的⽅式.作为发布订阅的⽅式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。⼀个接收端只能接收他创建以后发送客户端发送的信息。作为subscriber ，在接收消息时有两种⽅法，destination的receive⽅法，和实现message listener 接⼝的onMessage ⽅法。
如何解决消息重复问题？
所谓消息重复，就是消费者接收到了重复的消息,⼀般来说我们对于这个问题的处理要把握下⾯⼏点,
①.消息不丢失(上⾯已经处理了)
②.消息不重复执⾏
⼀般来说我们可以在业务段加⼀张表,⽤来存放消息是否执⾏成功，每次业务事物commit之后，告知服务端，已经处理过该消息，这样即使你消息重发了，也不会导致重复处理
⼤致流程如下:
业务端的表记录已经处理消息的id，每次⼀个消息进来之前先判断该消息是否执⾏过，如果执⾏过就放弃，如果没有执⾏就开始执⾏消息，消息执⾏完成之后存⼊这个消息的id
ActiveMQ消息发送失败?
ActiveMQ有两种通信⽅式，点到点形式和发布订阅模式。如果是点到点模式的话，如果消息发送不成功，此消息默认会保存到ActiveMQ服务端直到有消费者将其消费，所以此消息是不会丢失的。如果是发布订阅模式的通信⽅式，默认情况只通知⼀次，如果接受不到此消息就没有了，这种场景使⽤于对消息发送率要求不⾼的情况，如果要求消息必须送达不可以丢失的话，需要配置持久订阅。每个订阅端定义⼀个id，在订阅是向ActiveMQ注册，发布消息和接受消息时需要配置发送模式为持久化，此时如果客户端接受不到消息，消息会持久化到服务端，直到客户端正常接收后为⽌。
丢消息怎么办?
解决⽅案：⽤持久化消息【可以使⽤对数据进⾏持久化JDBC，AMQ(⽇志⽂件)，KahaDB和LevelDB】，或者⾮持久化消息及时处理不要堆积，或者启动事务，启动事务后，commit()⽅法会负责任的等待服务器的返回，也就不会关闭连接导致消息丢失了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。