ActiveMQ
安全 可靠 解耦合 异步 高吞吐 低延迟
安装：
下载地址：https://activemq.apache.org/components/classic/download/
windows版本
解压，打开bin目录下的bat文件。
启动后
8161端口可以看到网页版
密码默认为admin admin
home ：当前borker实例的信息
Queues:队列 点对点 消息被消费后 mq才会被删除
Toptics:主题 现有消费者等待，消息来直接发送，如果没有消费者 消息同样会发送，这样消息相当于丢失 因为没有消费者收到
Subscribers：订阅
Connections：链接信息 支持的协议 mqtt相应速度最高
Network:集群、分布式、高可用等信息
Scheduled:调度
Send：发送消息体
消息中间件应用场景
异步通信
有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们.
缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
如果突然并发量大了，可以通过mq先将消息存放，等待消费者处理，起到缓冲作用。
解耦
降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
常用消息队列（ActiveMQ、RabbitMQ、RocketMQ、Kafka）比较
JMS中的一些角色：
Broker
消息服务器，作为server提供消息核心服务。启动一个activemq实例就是一个Broker
Provider 生产者
消息生产者是由会话出创建的一个对象，用于把消息发送到一个目的地
Consumer 消费者
消费者是由会话创建的一个对象，它用于接受发送到目的地的消息。消息的消费可以采用以下两种方法之一：
同步消费 通过调用消费者的receive方法从目的地中显式的提取消息。receive方法可以一直阻塞到消息到达。
异步消费 客户可以为消费者注册一个消息监听器，定义在消息到达时所采取的动作。
p2p (消费者跟active mq是长链接)
基于点对点的消息模型
消息生产者生产消息发送到 queue 中，然后消息消费者从 queue 中取出并且消费消息。 消息被消费以后，queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消
息。
Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费、其它 的则不能消费此消息了。 当消费者不存在时，消息会一直保存，直到有消费消费
基于订阅/发布的消息模型
消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消
息。
和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。 当生产者发布消息，不管是否有消费者。都不会保存消息,就是说生产者生产了消息，不管有没有消费者，直接发送，发送完毕后直接删除。所以一定要先有消息的消费者，后有消息的生产者。
Queue
队列存储，常用与点对点消息模型
默认只能由唯一的一个消费者处理。一旦处理消息删除。如果消息有超时时间的话 消息就有可能丢失
Topic
主题存储，用于订阅/发布消息模型
主题中的消息，会发送给所有的消费者同时处理。只有在消息可以重复处 理的业务场景中可使用。
Queue/Topic都是 Destination 的子接口
ConnectionFactory
连接工厂，jms中用它创建连接
连接工厂是客户用来创建连接的对象，例如ActiveMQ提供的ActiveMQConnectionFactory。
Connection
JMS Connection封装了客户与JMS提供者之间的一个虚拟的连接。
Destination
消息的目的地
目的地是客户用来指定它生产的消息的目标和它消费的消息的来源的对象。JMS1.0.2规范中定义了两种消息传递域：点对点（PTP）消息传递域和发布/订阅消息传递域。 点对点消息传递域的特点如下：
每个消息只能有一个消费者。
消息的生产者和消费者之间没有时间上的相关性。无论消费者在生产者发送消息的时候是否处于运行状态，它都可以提取消息。
发布/订阅消息传递域的特点如下：
每个消息可以有多个消费者。
生产者和消费者之间有时间上的相关性。
订阅一个主题的消费者只能消费自它订阅之后发布的消息。JMS规范允许客户创建持久订阅，这在一定程度上放松了时间上的相关性要求 。持久订阅允许消费者消费它在未处于激活状态时发送的消息。
在点对点消息传递域中，目的地被成为队列（queue）；在发布/订阅消息传递域中，目的地被成为主题（topic）。
Session
JMS Session是生产和消费消息的一个单线程上下文。会话用于创建消息生产者（producer）、消息消费者（consumer）和消息（message）等。会话提供了一个事务性的上下文，在这个上下文中，一组发送和接收被组合到了一个原子操作中。
JMS的消息格式
JMS消息由以下三部分组成的：
消息头。
每个消息头字段都有相应的getter和setter方法。
消息属性。
如果需要除消息头字段以外的值，那么可以使用消息属性。
消息体。
JMS定义的消息类型有TextMessage、MapMessage、BytesMessage、StreamMessage和ObjectMessage。
TextMessage
文本消息
MapMessage
k/v
BytesMessage
字节流
StreamMessage
java原始的数据流
ObjectMessage
序列化的java对象
多消费者：
轮询消费，如果消费速度不一样的话，就是消费速度块的消费的消息就会多。
