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。
配置方式
- 静态方式
- 动态方式