消息中间件 MQ

topic quene区别

消息中间件应用场景: 异步/解耦/销锋

JMS ：Java MessageService

Broker: 消息服务器
Provider: 生产者
Consumer: 消费者

p2p(Quene): 基于点对点的消息模型, Provider发送消息到quene中， Consumer取消息。 可以有多个Consumer，但消息只能被取走一次。 没有Consumer，消息会被保留在quene中， 直到被取走。
也就是说， quene中的消息只能被取走一次，没有被取走就被保留。
pub/sub（Topic)：基于订阅/发布的消息模型 消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消 息。 和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。 当生产者发布消息，不管是否有消费者。都不会保存消息 一定要先有消息的消费者，后有消息的生产者。

ConnectionFactory：连接工厂
Connection： 虚拟的连接
Destination：消息的目的地
Session：生产和消费消息的一个单线程上下文。会话用于创建消息生产者（producer）、消息消费者（consumer）和消息（message）等

消息可靠性机制
确认 JMS消息
只有在被确认之后，才认为已经被成功地消费了。

消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。

在事务性会话中，当一个事务被提交的时候，确认自动发生。

在非事务性会话中，消息何时被确认取决于创建会话时的应答模式（acknowledgement mode）。该参数有以下三个可选值：

Session.AUTO_ACKNOWLEDGE。当客户成功的从receive方法返回的时候，或者从MessageListener.onMessage方法成功返回的时候，会话自动确认客户收到的消息。
Session.CLIENT_ACKNOWLEDGE。客户通过消息的acknowledge方法确认消息。需要注意的是，在这种模式中，确认是在会话层上进行：确认一个被消费的消息将自动确认所有已被会话消费的消息。例如，如果一个消息消费者消费了10个消息，然后确认第5个消息，那么所有10个消息都被确认。
Session.DUPS_ACKNOWLEDGE。该选择只是会话迟钝的确认消息的提交。如果JMS Provider失败，那么可能会导致一些重复的消息。如果是重复的消息，那么JMS Provider必须把消息头的JMSRedelivered字段设置为true。

持久性
JMS 支持以下两种消息提交模式：

PERSISTENT。指示JMS Provider持久保存消息，以保证消息不会因为JMS Provider的失败而丢失。
NON_PERSISTENT。不要求JMS Provider持久保存消息。
优先级
可以使用消息优先级来指示JMS Provider首先提交紧急的消息。优先级分10个级别，从0（最低）到9（最高）。如果不指定优先级，默认级别是4。需要注意的是，JMS Provider并不一定保证按照优先级的顺序提交消息。

消息过期
可以设置消息在一定时间后过期，默认是永不过期。

ActiveMQ
协议：ActiveMQ支持的client-broker通讯协议有：TCP、NIO、UDP、SSL、Http(s)、VM。
quene: 服务端先发消息，客户端再启动，此时默认接收消息。
topic:服务端先发消息，客户端再启动，此时默认不接收消息， 消息过期，达到重发上限，将进入死信队列。
解决方法：
1：给消息设置一个超时时间 -> 死信队列 -> 拿出来 -> 重发
2：mq服务端内部监控长时间不消费的消息， 进行重投
死信队列可以保证时效性消息producer.setTimeToLive 设置过期

选择器
独占消费者：Queue queue = session.createQueue(“xxoo?consumer.exclusive=true”);
topic每个客户端都要消费，所以独占消费者只对quene有效，并且是在客户端配置。

设置监听器，取代同步操作：consumer.setMessageListener(new MyListener());
消息类型：
1：文本session.createTextMessage（）
2：序列化：session.createObjectMessage()
3:MapMessage session.createMapMessage()

RocketMq
producer
下面这三个消息producer相关
同步消息（返回broker接收状态）
异步消息（不返回broker接收状态）
单向消息（不返回broker接收状态）
顺序消息（返回broker接收状态）同一个quene中有序，不同的quene中无序

下面这两个消息message相关
延时消息（返回broker接收状态）
批量消息（消息集合，本质还是上面的几个消息）

事务消息（返回broken接收状态）: 两阶段事务，producer发送消息到RMQ_SYS_TRANS_HALF_TOPIC（半消息）， commit了的消息才会被投递，其它的不投递。
broker

返回broker接收状态: 代表发送到broker或则没有发送到broker. 发送到broker也不代表消息不会丢，要依赖刷盘方式。
刷盘方式：
FlushDiskType=SYNC_FLUSH（同步） SYNC_MASTER（同步master）ASYNC_MASTER(异步master默认)
sendStatus状态：
SEND_OK：发送成功，消息放入内存，丢不丢消息要看刷盘方式。
FLUSH_DISK_TIMEOUT：刷盘超时，指定同步刷盘，5s即为超时。FlushDiskType=SYNC_FLUSH,消息在内存，服务器拓机才会丢失些消息。
FLUSH_SLAVE_TIMEOUT：同步到Slave时超时（从服务器未能在默认超时时间5s内完成同步刷盘）FlushDiskType=SYNC_MASTER
SLAVE_NOT_AVAILABLE：无Slave服务器可用,FlushDiskType=SYNC_MASTER

消息发送失败
producer向broker超时不会重试
producer send方法自带重试
最多重试2次
同步模式：轮转到下一个broker重试
异步模式：本broker重试
重试不会超过设定的值，sendMsgTimeout， 默认10s
以上策略也是在一定程度上保证了消息可以发送成功。如果业务对消息可靠性要求比较高，建议应用增加相应的重试逻辑：比如调用send同步方法发送失败时，则尝试将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker。

消费速度慢的处理方式
提高消费并行度
批量方式消费
跳过非重要消息

重试
producer：这里主要是客户端发送到broker重试， 不作讨论。
consumer:
public enum ConsumeConcurrentlyStatus {
CONSUME_SUCCESS,
RECONSUME_LATER;
}
正常返回CONSUME_SUCCESS， broker改变消息偏移量，代表消费成功。

1：异常重试：返回RECONSUME_LATER， broker会重试；
2：超时重试：超出处理时间， broker会重试。
参考