ActiveMQ的高级特性
ActiveMQ的高级特性
1、消息的持久订阅
在之前的pub/sub模式中，消费者只能消费自它订阅之后的消息，这显然是不合理的，有的应用场景就需要获取之前的历史信息。因此需要设置消息的持久化订阅。
connection = factory.createConnection();
// 设置客户端的唯一ID
connection.setClientID("AAA");
//destination = session.createTopic("HelloActiveMQ");
Topic topic = session.createTopic("HelloActiveMQ");
//consumer = session.createConsumer(destination);
consumer = session.createDurableSubscriber(topic,"AAA");
同时生产者发送消息的时候要进行持久化，默认是持久化消息。
即使Broker宕机，只要在宕机前将消息发送出去，服务启动后，订阅者也可以收到之前的消息。
- 消息自身持久化
- 订阅者设置持久订阅
2、消息的持久化机制
消息的持久化存储也是保证可靠性的重要机制之一，消息发送到Broker上后，可以设置为持久化方式，即使Broker宕机，恢复后也可以发送未处理的消息，默认是持久化的。
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
ActiveMQ支持多种不同的持久化方式：
- KahaDB ，基于文件存储
- 储，默认的存储方式
- JDBC存储
- Memory存储
- LevelDB存储
- JDBC With Active MQ Journal
3、JMS的可靠性机制
相对于队列的可靠性机制，生产者相对于队列，消费者相对于队列。
-
事务性会话
session = connection.createSession(true,Session.AUTO_ACKNOWLEDGE);生产者：消息发送完毕后，需要进行commit，否则发送不到队列
消费者：消息收到后，也需要进行commit，否则队列中的消息得不到消费
-
非事务性会话
session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
AUTO_ACKNOWLEDGE：自动确认
- 异步：当onMessage方法正常执行完毕，若该方法出现异常，队列会进行重发，重发次数达到6次后消息进入死信队列。所以一般使用try-catch-finally将业务代码包起来。
- 同步：receive方法调用
CLIENT_ACKNOWLEDGE：需要手动确认，一次确认，可以确认之前的所有消息。
- 多个消费者消费同一批消息时，不确认的消息，会发给其它消费者。
DUPS_ACKNOWLEDGE：批量自动确认，但存在消息重复问题。
SESSION_TRANSACTED：事务提交，一次性可以单个和多个commit，或着rollback。
4、Request-Response模式
响应应答模式，JMS规范中并没有直接提供这种模式，需要手动借助消息头定制协议。
借助ReplyTo
生产者发送消息的时候，在消息头中设置该消息的唯一ID，和消费者收到消息后要回应的destination，然后消费者就可以将响应消息发到该destination中，生产者监控这个destination，进而可以得到回应消息。
唯一性ID可以区分消息，可能消费者对每一种消息的回应都是不同的。这个ID一般放到缓存这种公共的地方，生产者消费者都可以看见。
5、死信队列
用来保存处理失败或者过期的消息，出现以下几种情况，消息会被重发。
- 事务会话被回滚或者没有commit
- CLIENT_ACKNOWLEDGE情况下，没有调用acknowledge方法，或者调用了recoover方法。
- 自动确认消息的方法中出现了异常
一个消息被重发六次以后，就会进入死信队列，本质上还是一个普通的队列，只是存储已经过期的消息。
6、延迟队列
修改配置文件，增加延迟和定时支持
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" schedulerSupport="true">
需要把几个描述消息定时调度方式的参数作为属性添加到消息，broker端的调度器就会按照我们想要的行为去处理消息。
一共有4个属性
1：AMQ_SCHEDULED_DELAY ：延迟投递的时间
2：AMQ_SCHEDULED_PERIOD ：重复投递的时间间隔
3：AMQ_SCHEDULED_REPEAT：重复投递次数
4：AMQ_SCHEDULED_CRON：Cron表达式
7、Master/Slave模式
Master-Slave方式中，只有Master提供服务，Slave是实时的备份Master的数据，保证消息的可靠性，当Master失效时，Slave会自动升级为Master，客户端会自动连接到Slave上工作。
- 架构图
-
特点
- 只有Master对外提供服务
- 一个Master下面有一个或者多个Slaver
- 一个Slaver只能隶属一个Master
- 整个主从架构只能有一个Mater
- 主从数据的复制是同步的
-
主从架构的实现方式
- 基于文件（Shared File Sysytem）
利用共享文件系统实现ActiveMQ集群，基于默认的数据持久方式kahaDB完成，哪个节点先获取到共享文件的锁，哪个就是Master，其它的节点就是Slaver。
- 基于数据库
JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一样的，只是把共享文件系统换成了共享数据库。我们只需在所有的ActiveMQ的主配置文件中activemq.xml添加数据源，所有的数据源都指向同一个数据库。
然后修改持久化适配器。这种方式的集群相对Shared File System Master Slave更加简单，更加容易地进行分布式部署，但是如果数据库失效，那么所有的ActiveMQ实例都将失效。
- 基于LevelDB，需要zookeeper的支持
利用zookeeper的master选举机制，来实现ActiveMQ的主从模式。
8、ActiveMQ的集群架构
采用水平扩展的方式，提供了HA的一种方案。
- 结构：
- 特点
- 失败转移：该环境下，每个JMS客户端可能连接到任意一个broker节点，若该节点宕机则它会自动转移的另一台broker上，JMS客户端连接到borker的连接方式为failover://protocol
- 水平扩展：进行任意的水平扩展，添加broker即可
- 分布式存储：通过网络将消息进行分布式处理，将生产者对应的broker转移到消费者对应的broker。
- 配置方式
- 静态方式
- 动态方式