9.（ActiveMQ优化）消费端 prefetchSize 和 optimizeAcknowledge 解析

       ActiveMQ，在消息发送端有ProducerWindowSize的概念；ProducerWindowSize概念，是producer允许积压的消息的大小。如需了解ProducerWindowSize概念，请移步：ActiveMQ消息发送策略 

       ActiveMQ，在消费端也有所谓的窗口机制，类似于ProducerWindowSize的概念。在消费端通过设置 prefetchSize 就可以设置窗口的大小。

      不同的类型的队列，prefetchSize 的默认值也是不一样的，如下：

          ①持久化队列和非持久化Queue（队列），prefetchSize默认值为1000；

          ②持久化 topic ，prefetchSize 默认值为100；

          ③非持久化消息，prefetchSize 默认值为 Short.MAX_VALUE -1

批量加载--prefetchSize

       通过以上描述，我们基本上应该知道 prefetchSize 的作用了，消费端会根据 prefetchSize 的大小批量获取数据，比如说默认值是1000，那么消费者就会预先加载1000条数据到本地的内存中(unconsumedMessages队列中)

prefetchSize的设置方法

      在 createQueue 中，添加 consumer.prefetchSize 即可，如下：

Destination destination = session.createQueue("myQueue?consumer.prefetchSize=88");

既然有批量加载，那么一定有批量确认，这样才算是彻底的优化。

---

批量确认--optimizeAcknowledge

        ActiveMQ 提供了 optimizeAcknowledge 来优化确认，它标识是否开启优化ACK ，只有在 true 的情况下，prefetchSize 和 optimizeAcknowledge 参数才会有意义。

        批量确认，一方面可以减轻 消费端 的负担（不需要频繁的来确认消息）、减少通信的开销，另一方面由于延迟了确认（默认 ack 了 0.65 * prefetchSize 个消息后才确认，即prefetchSize=1000的话，有650条消息过来后，统一确认一次），Broker再次发送消息时，又可以批量发送。

optimizeAcknowledge的设置方法

        在 brokerUrl 中指定 optimizeAcknowledge 选项

ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.204.201:61616
?jms.optimizeAcknowledge=true&jms.optimizeAcknowledgeTimeout=10000");

       注意：如果 optimizeAcknowledge 为 true ，那么 prefetchSize 必须大于 0 。当 prefetchSize = 0 的时候，表示 consumer 通过 pull 方式从broker获取消息

---

总结：

       我们知道 optimizeAcknowledge 和 prefetchSize 的作用，两者协同工作，通过批量获取消息、延迟批量确认的方式，来达到一个高效的消息消费模型。它比仅减少了客户端在获取消息时的阻塞次数，还能减少每次获取消息时的网络通信开销。

       需要注意的是，如果消费端的消费速度比较高，通过这两者组合是能大大提升 consumer 的性能。如果 consumer 的消费性能本身就比较慢，设置比较大的 prefetchSize 反而不能有效的达到提升消费性能的目的。因为过大的 prefetchSize 不利于 consumer 端消息的负载均衡。因为通常情况下，我们都会部署多个 consumer 节点来提升消费端的消费性能。

       这个优化方案，还会存在另外一个潜在的风险，当消息被消费之后还没有来得及确认时，producer 端发生了故障，那么这些消息就有可能会被重新发送给其他的 consumer 消费端，那么这种分享就需要 producer 端能够容忍 重复 消息。

END