一、ActiveMQ介绍

ActiveMQ介绍

一、JMS
- 1.jms介绍
- 2.jms消息传递模式
- 3.JMS编码总体架构
二、消息中间件
三、ActiveMQ介绍
- 1.引入的原因
- - 1.1 原因
  - 1.2 遇到的问题
  - 1.3 解决思路
- 2.定义
- 3.特点
- - 3.1 异步处理
  - 3.2 应用系统之间解耦
  - 3.3 实际-整体架构
- 4.作用

一、JMS

1.jms介绍

jms是java消息服务接口规范，主要包含四大元素：生产者、消费者、消息、消息服务。
- 生产者：创建消息，并把消息发动到消息服务；
- 消费者：从消息服务接收消息；
- 消息服务：即MQ消息服务（broker），而生产者与消费者相对其均为客服端；
- 消息：整个消息服务的传输对象，消息包含消息头、消息属性、消息体；

常用消息头属性：JMSDestination(消息目的地，如果生产者指定了目的地，在发送时会改为生产者绑定的目的地)、JMSDeliveryMode(是持久还是非持久)、JMSExpiration(过期时间，默认永久)、JMSPriority(优先级，0-9，数值越大优先级越高，默认为4)、JMSMessageId(唯一的消息ID)；
消息属性：可视为消息头属性的扩展，通过setXxxProperty(k,v)设置；
消息体：封装消息的具体数据，发送与接收的消息体类型必须一致，消息体类型总共有5种，TextMessage、Mapmessage、BytesMessage、StreamMessage、ObjectMessage；

2.jms消息传递模式

jms消息传递模式有如下两种，
- 点对点消息传递模式（P2P）：消息发送到一个特殊队列(queue), 消费者从队列获取消息，一条消息只能被只能被一个消费者消费；
- 发布/订阅消息传递模式(publish-subscribe)：消息被发送到一个主题上(topic)，所有订阅了该主题的消费者，都能接收到消息。

3.JMS编码总体架构

JMS应用程序由如下基本模块组成
- 1.连接工厂对象，创建消息客户端(生产者、消费者)与消息服务端的连接(connection)；
- 2.连接对象，创建回话对象(session);
- 3.会话对象，创建生产者对象(producer)、消费者对象(consumer)以及消息对象(message)；
- 4.目的地(queue/topic)，点对点模式下目的地是队列(queue)，发布/订阅模式下目的地是主题(topic)，生产者把消息发送到目的地，消费者从目的地接收消息

Destination-目的地

总共有两大模式
- 队列（Queue）：队列是一种一对一的消息传递模式。在队列中，消息发送方（生产者）将消息发送到队列中，然后消息接收方（消费者）从队列中接收并处理消息。每条消息只会被一个消费者接收和处理，确保了消息的顺序性和唯一性。
  - 特点：
    - 每个消息只能有一个消费者，类似于1对1的关系。好比个人快递自己领自己的。
    - 消息的生产者和消费者之间没有时间上的相关性。无论消费者在生产者发送消息的时候是否处于运行状态，消费者都可以提取消息。好比我们的发送短信，发送者发送后不见得接收者会即收即看。
    - 消息被消费后队列中不会再存储，所以消费者不会消费到已经被消费掉的消息。
  - 主题（Topic）：主题是一种一对多的消息传递模式。在主题中，消息发送方（生产者）将消息发送到主题中，然后所有订阅该主题的消息接收方（消费者）都会收到该消息。每个消费者都可以独立地接收和处理消息，消息的传递是广播式的，可以实现发布-订阅模式。（类似公众号，N个人订阅，就有N个人收到消息）。 - 特点：
    - 生产者将消息发布到topic中，每个消息可以有多个消费者，属于1：N的关系；
    - 生产者和消费者之间有时间上的相关性。订阅某一个主题的消费者只能消费自它订阅之后发布的消息。
    - 生产者生产时，topic不保存消息它是无状态的不落地，假如无人订阅就去生产，那就是一条废消息，所以，一般先启动消费者再启动生产者。

二、消息中间件

消息中间件是实现了jms规范的落地产品，目前市场上主流的消息中间件有 ActiveMQ、Kafka、RocketMQ、RabbitMQ等。企业开发中使用消息中间件的主要目的是 解决耦合调用、抵御洪峰流量(削峰)等。 以下主要讲解ActiveMQ的使用。

三、ActiveMQ介绍

官网地址

1.引入的原因

1.1 原因

微服务架构后，链式调用是我们在写程序时候的一般流程,为了完成一个整体功能会将其拆分成多个函数(或子模块)，比如模块A调用模块B,模块B调用模块C,模块C调用模块D。但在大型分布式应用中，系统间的RPC交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式微服务架构的通例

1.2 遇到的问题

系统之间接口耦合严重
- 举个例子：如果系统A要发送数据给系统B和系统C，发送给每个系统的数据可能有差异，因此系统A对要发送给每个系统的数据进行了组装，然后逐一发送；
- 当代码上线后又新增了一个需求：把数据也发送给D，新上了一个D系统也要接受A系统的数据，此时就需要修改A系统，让他感知到D系统的存在，同时把数据处理好再给D。在这个过程你会看到，每接入一个下游系统，都要对系统A进行代码改造，开发联调的效率很低。
面对大流量并发时，容易被冲垮
- 每个接口模块的吞吐能力是有限的，这个上限能力如果是堤坝，当大流量（洪水）来临时，容易被冲垮。
- 举个例子秒杀业务：上游系统发起下单购买操作，我就是下单一个操作下游系统完成秒杀业务逻辑（读取订单，库存检查，库存冻结，余额检查，余额冻结，订单生产，余额扣减，库存减少，生成流水，余额解冻，库存解冻）
等待同步存在性能问题
- RPC接口上基本都是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的那个接口。比如A调用B/C/D都是50ms，但此时B又调用了B1，花费2000ms，那么直接就拖累了整个服务性能。

1.3 解决思路

解耦：要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；
削峰：设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；
异步：强弱依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力；

2.定义

面向消息的中间件（message-oriented middleware）MOM能够很好的解决以上问题，是指利用高效可靠的消息传递机制与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储、流量削峰，异步通信，数据同步等功能。
- 发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题topic中，在合适的时候，消息服务器回将消息转发给接受者。在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接受者的生命周期也没有必然的关系；
- 尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者。
ActiveMQ 是 Apache 推出的一款 开源免费的，完全支持 JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现的消息中间件（Message Oriented Middleware,MOM）

3.特点

3.1 异步处理

消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或者队列）上；
消息接收者则订阅或者监听该爱通道。一条消息可能最终转发给一个或者多个消息接收者，这些消息接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
这样的一种通信方式，就是所谓的“异步”通信方式，对于系统A来说，只需要把消息发送给MQ，然后系统B就会异步的去进行处理了，系统A不需要“同步”的等待系统B处理完成。
- 这样的好处是解耦