• 欢迎访问 winrains 的个人网站!
  • 本网站主要从互联网整理和收集了与Java、网络安全、Linux等技术相关的文章,供学习和研究使用。如有侵权,请留言告知,谢谢!

ActiveMQ消费消息原理解析

消息队列 winrains 来源:匠丶 1年前 (2019-08-31) 34次浏览
ActiveMQ消费消息有两种方式。一种是使用同步阻塞的MessageConsumer.receive()方法;另一种是使用消息监听器MessageListener。这里需要注意的是,在同一个session下,只能选择其中一种方式。

消费消息流程图

消费消息源码分析

ActiveMQMessageConsumer.receive,消费端同步接收消息的源码入口:

public Message receive() throws JMSException {
    checkClosed();
    checkMessageListener(); // 检查receive和MessageListener是否同时配置在当前的会话中
    sendPullCommand(0); // 如果PrefetchSizeSize为0并且unconsumerMessage为空,则发起pull命令
    MessageDispatch md = dequeue(-1); // 从unconsumerMessage出队列获取消息
    if (md == null) {
        return null;
    }
    beforeMessageIsConsumed(md);
    afterMessageIsConsumed(md, false); // 发送ack给到broker
    return createActiveMQMessage(md);// 获取消息并返回
}
public Message receive() throws JMSException {
    checkClosed();
    checkMessageListener(); // 检查receive和MessageListener是否同时配置在当前的会话中
    sendPullCommand(0); // 如果PrefetchSizeSize为0并且unconsumerMessage为空,则发起pull命令
    MessageDispatch md = dequeue(-1); // 从unconsumerMessage出队列获取消息
    if (md == null) {
        return null;
    }
    beforeMessageIsConsumed(md);
    afterMessageIsConsumed(md, false); // 发送ack给到broker
    return createActiveMQMessage(md);// 获取消息并返回
}

sendPullCommand(),发送pull命令从broker上获取消息,前提是prefetchSize=0并且unconsumedMessages为空。unconsumedMessage表示未消费的消息,这里面预读取的消息大小为prefetchSize的值。

protected void sendPullCommand(long timeout) throws JMSException {
    clearDeliveredList();
    if (info.getCurrentPrefetchSize() == 0 && unconsumedMessages.isEmpty()) {
        MessagePull messagePull = new MessagePull();
        messagePull.configure(info);
        messagePull.setTimeout(timeout);
        session.asyncSendPacket(messagePull); // 向服务端异步发送messagePull指令
    }
}

clearDeliveredList(),主要用来清理已经分发的消息链表deliveredMessagesdeliveredMessages,存储分发给消费者但还为应答的消息链表。如果session是事务的,则会遍历deliveredMessage中的消息放入到previouslyDeliveredMessage中来做重发;如果session是非事务的,根据ACK的模式来选择不同的应答操作。
dequeue(),从unconsumedMessage中取出一个消息,在创建一个消费者时,会对这个消费者创建一个未消费的消息通道,这个通道分为两种,一种是简单优先级队列分发通道SimplePriorityMessageDispatchChannel ;另一种是先进先出的分发通道FifoMessageDispatchChannel
通过这样的设计可以允许session能够一次性将多条消息分发给一个消费者,而不用消费者每次消费完一个消息以后再去broker拿消息,提高效率。默认情况下对于queue来说,prefetchSize的值是1000。
beforeMessageIsConsumed(),这里面主要是做消息消费之前的一些准备工作,如果ACK类型不是DUPS_OK_ACKNOWLEDGE或者队列模式(简单来说就是除了Topic和DupAck这两种情况),所有的消息先放到deliveredMessages链表的开头。并且如果当前是事务类型的会话,则判断transactedIndividualAck,如果为true,表示单条消息直接返回ack。否则,调用ackLater,批量应答, client端在消费消息后暂且不发送ACK,而是把它缓存下来(pendingACK),等到这些消息的条数达到一定阀值时,只需要通过一个ACK指令把它们全部确认,这比对每条消息都逐个确认,在性能上要提高很多。

private void beforeMessageIsConsumed(MessageDispatch md) throws JMSException {
        md.setDeliverySequenceId(session.getNextDeliveryId());
        lastDeliveredSequenceId = md.getMessage().getMessageId().getBrokerSequenceId();
        if (!isAutoAcknowledgeBatch()) {
            synchronized (deliveredMessages) {
                deliveredMessages.addFirst(md);
            }
            if (session.getTransacted()) {
                if (transactedIndividualAck) {
                    immediateIndividualTransactedAck(md);
                } else {
                    ackLater(md, MessageAck.DELIVERED_ACK_TYPE);
                }
            }
        }
    }

afterMessageIsConsumed(),这个方法的主要作用是执行应答操作,这里面做以下几个操作:
Ø 如果消息过期,则返回消息过期的ack
Ø 如果是事务类型的会话,则不做任何处理
Ø 如果是AUTOACK或者(DUPS_OK_ACK且是队列),并且是优化ack操作,则走批量确认ack
Ø 如果是DUPS_OK_ACK,则走ackLater逻辑
Ø 如果是CLIENT_ACK,则执行ackLater逻辑

消息的确认过程

消息确认有四种 ACK_MODE,分别是:
AUTO_ACKNOWLEDGE = 1 自动确认
CLIENT_ACKNOWLEDGE = 2 客户端手动确认
DUPS_OK_ACKNOWLEDGE = 3 自动批量确认
SESSION_TRANSACTED = 0 事务提交并确认
虽然 Client 端指定了 ACK 模式,但是在 Client 与 broker 在交换 ACK 指令的时候,还需要告知ACK_TYPE。ACK_TYPE 表示此确认指令的类型,不同的ACK_TYPE 将传递着消息的状态,broker 可以根据不同的 ACK_TYPE 对消息进行不同的操作。
ACK_TYPE:
DELIVERED_ACK_TYPE = 0 消息”已接收”,但尚未处理结束;
STANDARD_ACK_TYPE = 2 “标准”类型,通常表示为消息”处理成功”,broker 端可以删除消息;
POSION_ACK_TYPE = 1 消息”错误”,通常表示”抛弃”此消息,比如消息重发多次后,都无法正确处理时,消息将会被删除或者 DLQ(死信队列);
REDELIVERED_ACK_TYPE = 3 消息需”重发”,比如 consumer 处理消息时抛出了异常,broker 稍后会重新发送此消息;
INDIVIDUAL_ACK_TYPE = 4 表示只确认”单条消息”,无论在任何 ACK_MODE ;
UNMATCHED_ACK_TYPE = 5 在 Topic 中,如果一条消息在转发给“订阅者”时,发现此消息不符合 Selector 过滤条件,那么此消息将 不会转发给订阅者,消息将会被存储引擎删除(相当于在 Broker 上确认了消息)。

消息的重发机制原理

在正常情况下,有几中情况会导致消息重新发送:
Ø 在事务性会话中,没有调用 session.commit 确认消息或者调用session.rollback 方法回滚消息;
Ø 在非事务性会话中,ACK 模式为 CLIENT_ACKNOWLEDGE 的情况下,没有调用 acknowledge 或者调用了 recover 方法。
一个消息被重发超过默认的最大重发次数(默认 6 次)时,消费端会给 broker 发送一个”poison ack,告诉 broker 不要再发了。这个时候 broker 会把这个消息放到 DLQ(死信队列)。

ActiveMQ 的优缺点

ActiveMQ 采用消息推送方式,所以最适合的场景是默认消息都可在短时间内被消费。数据量越大,查找和消费消息就越慢,消息积压程度与消息速度成反比。
缺点:
1.吞吐量低。由于 ActiveMQ 需要建立索引,导致吞吐量下降。
2.无分片功能。这是一个功能缺失,JMS 并没有规定消息中间件的集群、分片机制。而由于 ActiveMQ 是为企业级开发设计的消息中间件,初衷并不是为了处理海量消息和高并发请求。如果一台服务器不能承受更多消息,则需要横向拆分。ActiveMQ 官方不提供分片机制,需要自己实现。
适用场景:
对 TPS 要求比较低的系统,可以使用 ActiveMQ 来实现,一方面比较简单,能够快速上手开发,另一方面可控性也比较好,还有比较好的监控机制和界面。
不适用的场景:
消息量巨大的场景。ActiveMQ 不支持消息自动分片机制,如果消息量巨大,导致一台服务器不能处理全部消息,就需要自己开发消息分片功能。

作者:匠丶

来源:https://www.jianshu.com/p/8cf82006504e


版权声明:文末如注明作者和来源,则表示本文系转载,版权为原作者所有 | 本文如有侵权,请及时联系,承诺在收到消息后第一时间删除 | 如转载本文,请注明原文链接。
喜欢 (1)