在说消息中间件之前，先说消息中间件的三种协议：
JMS(是一套规范，java的接口api，主要用于规范消息中间件的接口。可以类别与jdbc之于数据库，jms时java平台的消息中间件通用规范接口，具体的实现由各大消息中间件厂商提供。)
MQTT(是一种IM通讯协议，专为小型无声设备之间通过低带宽发送短消息而设计，多应用于物联网设备，协议简单、流量小、计算量小、能耗低)
AMQP(全称为：Advanced Message Queuing Protocol,高级消息队列协议，需要跨平台或语言或需要分布式事务的场景下可以使用AMQP)
- JMS (java message service),只应用在基于JVM的语言，
JMS组成：
- JMS provider JMS消息中间件(例如：ActiveMQ,rabbitMQ,kafka)
- JMS producer
- JMS consumer
- JMS message
JMS message
JMS中间件，需要给消息生产方和消息的消费方使用，内部的格式必须保持一致，两边才可以解析。
message结构：
- 消息头
- 消息头中包含了消息的设置信息，例如：投放的目的地（topic、partation）、消息的唯一标识 messageId（一般JMS会自动生成，也可由生产方来主动生成）
- 消息体
- message实际放数据的地方，有多重类型 text、map、bytes、stream、
- 消息属性
- 如果是除消息头外的值，可以使用消息属性，因为消息头中的属性是固定的，类似自定义字段，重点标注消息头和消息体的消息，message.setStringProperty("key","VALUE") 一般怎么使用，限制是什么
JMS传输模型、核心组件
传输模型
- P2P (point to point) 点对点消息传输模型，消息提供方和消息消费方通过先进先出队列 提供给消息消费者，消息消费者从队列主动拉取数据。
特点：
- 1对1
- 消费者主动拉取数据
- 消息收到后消息清楚
编辑切换为居中
添加图片注释，不超过 140 字（可选）
- PUB/SUB模式 （发布订阅模式）发布订阅模式是一个基于消息传送的模型。发布订阅模型可以有多种不同的订阅者,临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，出于离线状态。
特点：
- 1对多
- 数据生产后推送给所有订阅者
编辑切换为居中
添加图片注释，不超过 140 字（可选）
核心组件
- Destination 消息发送的目的地，上面说的queue和topic
- message 被发送的消息
- producer 消息的生产者，发送消息必须通过生产者来发送
- consumer 与生产者对应，这是消息的消费者和接收者，通过它来接收一个消息
编辑切换为居中
添加图片注释，不超过 140 字（可选）
| 接口名称 | p2p | pub/sub | 备注 |
|---|---|---|---|
| connectionFactory | queueConnectionFactory | TopicConnectionFactory | 基于工厂模式，创建和jms提供者之间的链接，需要制定链接的url和协议，任何jms客户端和jms提供者之间的交互，都必须要制定链接 |
| Destination | queue | topic | ”目的地“ jms提供者用于标记消息所属类型的标记 |
| connection | queueConnection | topicConnection | ”链接“用于描述一个具体的链接入udp和tcp，任何交互数据都需要通过这个链接进行，jms实现者定义数据格式（协议），在物理层用于区分jms客户端，一般而言，一个应用只有一个“链接”。 |
| session | queueSession | topicSession | ”会话“，在逻辑上用于区分jms客户端，因为链接可被共用已提高网络利用率，每个session可以支持相对独立的事务和相关属性，每个session都有ID |
| message | "消息"，jms api中提供了多种message类型，它们有各自的”序列化/反序列化“机制；消息中可以包含多种jms属性以及客户端自定义的消息属性和内容 | ||
| producer | queueSender | TopicPublisher | “生产者”，一种可以向jms提供者提交消息的客户端类型 |
| consumer | queueReceiver | TopicSubscriber | ”消费者“一种可以向jms获取消息的客户端类型 |
JMS的可靠性
JMS提供了持续化/ack确认机制/事务 来保证消息的可靠性（防止消息丢失，消息的重复消费）
- 持久化
- 当服务宕机时，数据不丢失，会保存在服务器本地，持久化可以保证消息在未被消费方消费前不丢失，默认为持久化传送模式，保证消息只被传输一次和消费一次，可靠性是优先考虑因素。
- topic持久化，消费者需要在MQ注册一个自己的身份id标识，在消费者宕机时，生产者会为对应的id保留数据。
- 事务
- acid生产者消费者为了保证多条消息发送保证同步提交和同步消费，可以开启事务功能，需要提交事务，
编辑切换为居中
添加图片注释，不超过 140 字（可选）
- 从发送这角度来看，jms提供者为这组消息提供了高速缓存，知道执行commit为止，如果发生了故障或者执行了rollback操作，这些消息就会丢弃，在一个事务中传送给消息服务器的消息，它并不会转发给消费者，直到生产者生产完消息并执行了commit操作为止。
- 从消费者角度来看，jms支持事务的接收，jms提供者在提供这些消息给消费者时，消费者消费这些消息要么全部接收，要么一条也不接收，这些消息会尽快传给接收者，但是它们一直由jms提供者保存，直到接收者在会话对象上执行commit为止，如果发送发生了故障或者执行了rollback操作，提供者会试图重新发送消息，在这种情况下，这些消息会设置重新传送标记。
编辑切换为居中
添加图片注释，不超过 140 字（可选）
- ACK确认机制
- 1.自动ack消费者自动ack
- 2.手动ack 需要自己手动提交ack信息
- 3.运行重复签收，用于可以多消费者签收的消息
事务和ack都是消息确认的方式，同时存在时事务的优先级要高一些，开启事务时ack是无效的，非事务的模式下，ack开启才有效。
