ActiveMQ

参考文档

https://blog.csdn.net/whiteforever/article/details/49929235
http://blog.163.com/_kid/blog/static/3040547620161634230453/

Queue和Topic

JMS中定义了两种消息模型：点对点（point to point， queue）和发布/订阅（publish/subscribe，topic）。主要区别就是是否能重复消费。

Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费、其它的则不能消费此消息了。
当消费者不存在时，消息会一直保存，直到有消费消费

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。当生产者发布消息，不管是否有消费者。都不会保存消息（不落地）。每个消费者得到的都是一份完整的消息。

总体结构

为了更好的维护TCP链路的使用，ActiveMQ采用了心跳机制作为判断双方链路的健康情况。ActiveMQ使用的是双向心跳，也就是ActiveMQ的Broker和Client双方都进行相互心跳。

consumer机制

consumer会维护两个队列，pendingList和dispatchedList，前者存放从broker已接受但未消费（未回调onMessage）的message，后者用于存放已消费但未确认的message（可用于recover，即redelivery）。

activemq的重发机制是session为单位的，并且重发只发生在client端，并不会向broker请求重发消息，只会在重发后向broker发送一个redelivered消息，如果某消息的redelivered次数达到阈值，这条消息就会被清除并送入DLQ。

死信队列（DLQ）

一旦消息重发尝试超过重发策略中配置的maximumRedeliveries(缺省为6次)时，会给broker发送一个”Poison ack”，通知它，这个消息被认为是一个毒丸(a poison pill)，接着broker会将这个消息发送到DLQ(Dead Letter Queue)，以便后续分析处理。 缺省死信队列(Dead Letter Queue)叫做ActiveMQ.DLQ;所有的未送达消息都会被发送到这个队列，

ActiveMQ的prefetch机制

当消费者去获取消息时，不会一条一条去获取，而是一次性获取一批，默认是1000条。这些预获取的消息，在还没确认消费之前，在管理控制台还是可以看见这些消息的，但是不会再分配给其他消费者，此时这些消息的状态应该算作“已分配未消费”，如果消息最后被消费，则会在服务器端被删除，如果消费者崩溃，则这些消息会被重新分配给新的消费者。但是如果消费者既不消费确认，又不崩溃，那这些消息就永远躺在消费者的缓存区里无法处理。更通常的情况是，消费这些消息非常耗时，你开了10个消费者去处理，结果发现只有一台机器吭哧吭哧处理，另外9台啥事不干。解决方案：将prefetch设为1，每次处理1条消息，处理完再去取，这样也慢不了多少。

性能优化

1. Send/dispatch Async 影响非常大。同步异步的发送和投递，都非常影响吞吐量。另外，SystemUsage和PFC流控对同步发送有直接影响。
2. Not transacted 去掉了记录redo日志

3. Auto_ACK/Optim_ACK 优化确认

   减少交互次数
   4、Non-persistence 持久化消息，跟下面几点有关

   持久化和非持久化，也是数量级的影响，毕竟为了提高可靠性，使用数据库或文件来存消息，开销非常大。
   5、pendingQueuePolicy/vmQueueCursor 决定了消息存储+发送模式，影响很大

   内存最快，文件和jdbc方式更安全，但是非常慢。。。
   6、producerFlowControl/memoryLimit 可能会直接block掉producer

   vmCursor+非持久时，直接变成一个内存MQ，为了不爆掉jvm，在消息积压到指定数量的时候，PFC会阻止生产消息。
   7、fast/slow consumer 决定了消息处理模式

   跟上面几点有关系。

8、在connection或connectionFactory上关闭掉 copyMessageOnSend

根据JMS规范，消息是不可变的。send的时候，会自动的添加一些属性。有时候，可能会重用，或者多线程处理。为了不影响消息的不可变性，发送的时候，先复制一份，这样，发送时处理的消息对象和你的代码持有的消息对象，是两个不同对象了。相互之间就不会互相影响了。
一般情况下，这个选项可以关闭，从而获得一定的性能提升。
9、consumer端，获取消息时候的prefetchSize设置。 一定范围情况下，一次预获取越大，总体性能越好。