ActiveMQ整理

消息中间件三大作用：异步、解耦、削峰

完全支持JMS协议和J2EE规范

JMS协议是一个接口规范类似于JDBC，与厂商无关的提供方法

JMS的消息模式：

点对点
发布订阅

JMS API对象

activeMQ的安装

activemq的访问

原生JMS操作

除了一个监听器还有一个普通接收

spring整合

基于配置文件

springboot整合

JMS协议结构和 JMS Message

消息头

消息体

objectmessage必须要序列化而且activemq5.12后为了安全考虑，activemq默认不接受自定义对的序列化对象，需要自定义加到受信任的列表里

消息属性

消息持久化

内存

日志

存入数据库
首先要加上delivery-mode持久化配置
修改activemq.xml
现在我们需要导入进linux两个jar包（mysql连接和druid）

消息事务

原子性
事务性的发送，要调用事务commit方法MQ才去把消息存储和确认

消费者这边也有事务（不明显原因：），只是他是在一条消息里面的不是多条消息里面，如果消费者消费到了那么他就会确认消息收到，然后MQ服务器就会把消息删除掉
如果消费者抛出异常或者主动对事务进行回滚，那么消息有一个重发这么一个机制

生产者：
事务性发送方案一：原生JMS
事务性发送方案二：JMS事务管理器

消费者的事务接收
只需要加一个session，然后用session去提交回滚事务即可

确认机制

消费者监控MQ接收消息，然后返回一条确认消息，最后MQ移除消息

确认机制跟这个事务有紧密联系的，如果我们在消费方开启了事务，消费方接收到了消息之后会自动确认给MQ服务器说确认消息

如果我们没有事务

消息合适被确认取决于创建会话时候的第二个参数应答模式，有三个参数可供选择，之前我们一直选择的第一个

消息投递方式

异步投递

异步投递如何确认成功

延时投递

修改ActiveMQ.xml

定时投递

启动类@EnableScheduling
在生产者添加Scheduling的定时类

死信队列

什么是死信队列

死信队列是MQ产品在处理失败或者过期的情况下来保证消息不会丢失的机制，

哪些消息会处理失败？

重发失败6次的时候，当然这个可以设置，重发时间也可以设置
MQ在遇到事务开启手动调用rollback
开启事务但是没有commit
未开启事务，手动确认，我们手动调用session.recover（）

死信队列配置调整

实际开发中可能有很多队列，每个队列都有失败消息，如果把所有队列的失败消息都放在一个队列里面不好处理这些失败消息，我们需要把每一个队列放到他们自己的死信队列里面去
修改ActiveMQ.xml

RedeliveryPolicy重发策略设置
刚才我们在测试的时候重发了6次，其实这个次数也是可以改的，间隔时间默认是1秒其实也是可以改的