消息游标

如果消费者够快的话，消息会被及时消费，否则堵塞的消息会被存储（消息游标被pending）

当队列中的消息被消费完时，阻塞的消息被重新消费。

消息游标共有三类：Store based Cursor （默认的），VM Cursor（速度快，但对于非常慢的消费者或消费者长时间短看的情况不适用），File based Cursor（VM Cursor的升级版）

对于Topics来说，每一个subscriber，服务端都会维护一个queue 和一个 pending cursor.  因此对于持久和非持久订阅要配置不同的策略

一些应用可能只是简单的丢弃过期消息，而不想将它们放到DLQ中，完全跳过了DLQ。在dead letter strategy死信策略上配置processExpired属性为false，可以实现这个功能。 
 
   
     
       
       <!-- Set the following policy on all queues using the '>' wildcard -->  
         
         <!--  
           Tell the dead letter strategy not to process expired messages  
           so that they will just be discarded instead of being sent to  
           the DLQ  
         -->  
           
           processExpired="false" />  
           
         
       
     
   
...  
 

消息头
一个消息对象分为三部分：消息头(Headers)，属性（Properties）和消息体（Payload）。对于StreamMessage和 MapMessage，消息本身就有特定的结构，而对于TextMessage，ObjectMessage和BytesMessage是无结构的。一个消息可以包含一些重要的数据或者仅仅是一个事件的通知。
消息的Headers部分通常包含一些消息的描述信息，它们都是标准的描述信息。包含下面一些值：
JMSDestination
消息的目的地，Topic或者是Queue。

JMSDeliveryMode
消息的发送模式：persistent或nonpersistent。前者表示消息在被消费之前，如果JMS提供者DOWN了，重新启动后消息仍然存在。后者在这种情况下表示消息会被丢失。可以通过下面的方式设置：
Producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

JMSTimestamp
当调用send()方法的时候，JMSTimestamp会被自动设置为当前事件。可以通过下面方式得到这个值：
long timestamp = message.getJMSTimestamp();

JMSExpiration
表示一个消息的有效期。只有在这个有效期内，消息消费者才可以消费这个消息。默认值为0，表示消息永不过期。可以通过下面的方式设置：
producer.setTimeToLive(3600000); //有效期1小时 （1000毫秒 * 60秒 * 60分）

JMSPriority
消息的优先级。0-4为正常的优先级，5-9为高优先级。可以通过下面方式设置：
producer.setPriority(9);

JMSMessageID
一个字符串用来唯一标示一个消息，J主要是用来关联多个Message，例如需要回复一个消息的时候，通常把回复的消息的JMSCorrelationID设置为原来消息的ID。

JMSReplyTo
有时消息生产者希望消费者回复一个消息，JMSReplyTo为一个Destination，表示需要回复的目的地。当然消费者可以不理会它。

JMSCorrelationID
通常用来关联多个Message。例如需要回复一个消息，可以把JMSCorrelationID设置为所收到的消息的JMSMessageID。

JMSType
表示消息体的结构，和JMS提供者有关。

JMSRedelivered
如果这个值为true，表示消息是被重新发送了。因为有时消费者没有确认他已经收到消息或者JMS提供者不确定消费者是否已经收到。

除了Header，消息发送者可以添加一些属性(Properties)。这些属性可以是应用自定义的属性，JMS定义的属性和JMS提供者定义的属性。我们通常只适用自定义的属性。

                                  内存设置

ACTIVEMQ_OPTS的配置〉=memoryUsage中配置〉=所有durable desitination设置之和

ACTIVEMQ_OPTS 设置为4到6G，memoryUsage 5G，每一个producer的内存设置为32mb,设置的最大连接数为1000.       1000*32大约30G，远远大于5G 的memoryUsage，和4到6G的ACTIVEMQ_OPTS。      建议适当调整producer的内存限制或连接数。

broker中还可以单独配置生产者使用的producerSystemUsage 和消费者使用的consumerSystemUsage，格式跟systeUsage一样。

默认情况下，没有配置producerSystemUsage 和 consumerSystemUsage，则生产者和消费者都使用systemUsage。

这时可能会因为生产者线程把内存用完，导致消费者线程处理缓慢甚至无法消费的问题。这种情况下，添加消费端的机器和消费者数量可能都无法增加消费的速度。

解决办法就是：

在broker上设置splitSystemUsageForProducersConsumers=”true”，使得生产者线程和消费者线程各使用各的内存。

默认是 生产者线程内存：消费者线程内存 = 6:4。

也可以通过如下两个参数设置生产者线程内存和消费者线程内存各一半：

producerSystemUsagePortion = 50

consumerSystemUsagePortion = 50

                                        流控制

消费者流控

消费者端，一般来说消费的越快越好，broker的积压越小越好。

但是考虑到事务性和客户端确认的情况，如果一个消费者一次获取到了很多消息却都不确认，这会造成事务上下文变大，broker端这种“半消费状态”的数据变多，所以ActiveMQ有一个prefetchSize参数来控制未确认情况下，最多可以预获取多少条记录。

默认情况如下：

持久化queue：1000条

非持久化queue： 1000条

持久化topic：100条

非持久化topic： 无限制

可以通过3中方式设置prefetchSize

1、  tcp://localhost:61616?jms.prefetchPolicy.all=50

2、  tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=1

3、  queue = new ActiveMQQueue("TEST.QUEUE?consumer.prefetchSize=10");