参考文档
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条消息,处理完再去取,这样也慢不了多少。
性能优化
- Send/dispatch Async 影响非常大。同步异步的发送和投递,都非常影响吞吐量。另外,SystemUsage和PFC流控对同步发送有直接影响。
- Not transacted 去掉了记录redo日志
Auto_ACK/Optim_ACK 优化确认
减少交互次数
4、Non-persistence 持久化消息,跟下面几点有关持久化和非持久化,也是数量级的影响,毕竟为了提高可靠性,使用数据库或文件来存消息,开销非常大。
5、pendingQueuePolicy/vmQueueCursor 决定了消息存储+发送模式,影响很大内存最快,文件和jdbc方式更安全,但是非常慢。。。
6、producerFlowControl/memoryLimit 可能会直接block掉producervmCursor+非持久时,直接变成一个内存MQ,为了不爆掉jvm,在消息积压到指定数量的时候,PFC会阻止生产消息。
7、fast/slow consumer 决定了消息处理模式跟上面几点有关系。
8、在connection或connectionFactory上关闭掉 copyMessageOnSend
根据JMS规范,消息是不可变的。send的时候,会自动的添加一些属性。有时候,可能会重用,或者多线程处理。为了不影响消息的不可变性,发送的时候,先复制一份,这样,发送时处理的消息对象和你的代码持有的消息对象,是两个不同对象了。相互之间就不会互相影响了。
一般情况下,这个选项可以关闭,从而获得一定的性能提升。
9、consumer端,获取消息时候的prefetchSize设置。 一定范围情况下,一次预获取越大,总体性能越好。