ActiveMQ学习笔记（15）----Message Dispatch高级特性（一）

1. Message Cursors

　　1.1 概述

　　ActiveMQ发送持久化消息的典型的厝里方式是：当消息的消费者准备就绪时，消息发送系统把存储的消息按批次发送给消费者，在发送完一个批次的消息后，指针的标记位置指向下一个批次的待发消息的位置，进行后续的发送操作。这是一种 比较健壮和灵活的消息发送方式，但是大多数的情况下，消息的消费者不一定一直都处于这种理想的活跃状态。

　　因此，从ActiveMQ5.0.0版本开始，消息发送系统采用一种混合型的发送模式，当消息消费者处于活跃状态时，允许消息发送系统直接把持久化消息发送给消费者，当消费者处于不活跃状态下时，切换使用Cursors来处理消息的发送。

　　当消息的消费者处于活跃状态并且处理能力较强时，被持久化存储的消息直接发送到与消费者相关联的发送队列，如下：

　　

　　当消息已经出现积压，消费者再开始活跃，或者是消费者的消费速度比消息的发送速度慢时，消息将从Pending Cursor中提取，并发送与消费者关联的发送队列。见下图：

　　

　　1.) Store-base

　　　　从ActiveMQ5.0 开始，默认使用此种类型的cursor,其能够满足大多数场景的使用要求。同时支持非持久消息的处理，Store-based内嵌了File-based的模式，非持久消息直接被Non-persistent pending Cursor所处理。工作模式见下图：

　　

　　2）. VM

　　相关消息引用存储在内存中，当满足条件时，消息直接被发送到消费者与值相关的发送队列，处理速度非常快，但出现慢消费或者消费者长时间处于不活跃状态的情况下，无法适应。工作模式见下图：

　　

　　3) .File-based

　　　当内存设置达到设置的限制，消息被存储到磁盘中的临时文件中。工作模式见下图:

　　

　　4). 配置使用

　　在缺省的情况下，ActiveMQ会根据使用的Message Store来决定使用何种类型的Message Cursors，但是可以根据destination来配置Message Cursors,例如：

　　1. 对Topic subscripbers

 <destinationPolicy>
            <policyMap>
              <policyEntries>
                <policyEntry topic="org.apache" producerFlowControl="false" memoryLimit="1mb">
                    <dispatchPolicy>
                        <<strictOrderDispatchPolicy/>
                    </dispatchPolicy>
                    <deadLetterStrategy>
                        <individualDealLetterStrategy  topicPrefix="Test.DLQ"/>
                    </deadLetterStrategy>
                    <pendingSubscriberPolicy>
                        <vmCursor/>
                    </pendingSubscriberPolicy>
                    <pendingDurableSubscriberPolicy>
                        <vmDurableCursor/>
                    </pendingDurableSubscriberPolicy>
                </policyEntry>
              </policyEntries>
            </policyMap>
        </destinationPolicy>

　　配置说明：

　　有效的Subscriber类型是vmCursor和fileCursor，缺省是store based cursor。有效的持久化subscribe的cursor types是storeDurableSubscriberCursor,vmDurableCursor和fileDurableSubscriberCursor,缺省是store based cursor.

　　2. 对于queue的配置

<destinationPolicy>
            <policyMap>
              <policyEntries>
        
                <policyEntry queue="org.apache.>" >
                    <deadLetterStrategy>
                        <individualDealLetterStrategy  topicPrefix="Test.DLQ"/>
                    </deadLetterStrategy>
                    <pendingQueuePolicy>
                        <vmQueueCursor/>
                    </pendingQueuePolicy>
                </policyEntry>
              </policyEntries>
            </policyMap>
        </destinationPolicy>

2. Async Sends

　　ActiveMQ支持异步和同步发送消息，是可以配置，通常对于快的消费者，是直接把消息同步发送过去，但是对于一个慢消费者，你使用同步发送消息可能出现producer堵塞等现象，慢消费者适合异步发送。

　　配置使用：

　　1. ActiveMQ默认设置dispatchAsync=true是最好的性能设置。如果你处理Fast Consumer则使用dispatchAsync=false

　　2. 在Connection URI级别来配置使用Async Send

　　　　factory = new ActiveMQConnectionFactory("tcp://127.0.0.1:61616?jms.useAsyncSend=true");

　　3. 在ConnectionFactory级别来配置使用Async Send

　　　　factory.setUseAsyncSend(true);（此方法是存在于ActiveMQConnectionFactory中的）

　　4. Connection级别来配置使用Async Send

　　　　connection.setUseAsyncSend(true); (此方法存在于ActiveMQConnection中)

3. Dispatch Policies (消息分发策略)

　　3.1 严格顺序分发策略（Strict Order Dispatch Policy）

　　通常ActiveMQ会保证topic consumer以相同的顺序接收来意同一个producer的消息，并且有时候也需要保证不同的topic consumer以相同的数据接收消息，但是，由于多线程和异步处理，不同的topic consumer可能会以不同的顺序接收来自不同producer的消息。

　　Strict order dispatch policy 会保证每个topic consumer会以相同的顺序接收消息，代价就是性能上的损失。以下是一个配置例子：

<policyEntry topic="ORDERS.>">
    <dispatchPolicy>
        <strictOrderDispatchPolicy/>
     </dispatchPolicy>
</policyEntry>    

　　对于Queue的配置为：

<policyEntry queue=">" stricOrderDispatch="false"/>

　　3.2  轮询的分发策略（Round Robin Dispatch Policy）

　　　ActiveMQ的prefetch缺省参数，是针对处理大量消息时的高性能和高吞吐量而设置的，所以缺省的prefetch参数比较大，而且缺省的dispatche policies会尝试尽可能快的填满缓冲。

　　然而有些情况下，例如只有少量的消息而且单个消息的处理时间比较长，那么在缺省的prefetch和dispatch policies下，这些少量的消息总是倾向于被分发到个边的consumer上，这样就会因为负载的不均衡而导致处理时间的增加。

　　Round Robin dispatch policy会尝试平均分发消息，以下是一个例子：

<policyEntry topic="FOO.>">
    <dispatchPolicy>
        <roundRobinDispatchPolicy/>
    </dispatchPolicy>
</policyEntry>