摘要：本文旨在指出中集成的一些性能陷阱，在另一篇文章各組件詳解里有組件介紹及如何正確使用的內(nèi)容。因此的做法會(huì)大大降低性能，并且將大部分的時(shí)間都花在反復(fù)重建這些對(duì)象上。提供的可以讓使用避免頻繁創(chuàng)建的問(wèn)題。至于使用的性能測(cè)試則留給同學(xué)自己做了。

Github

本文旨在指出Spring/Spring Boot中集成JMS的一些性能陷阱，在另一篇文章Spring JMS各組件詳解里有Spring JMS組件介紹及如何正確使用的內(nèi)容。

Spring提供了JmsTemplate用來(lái)簡(jiǎn)化JMS的操作，但是JmsTemplate的性能是有很大問(wèn)題的，主要體現(xiàn)在以下幾個(gè)方面：

根據(jù)Artemis官方文檔的說(shuō)法，JmsTemplate是一種anti-pattern，如果在使用JmsTemplate的情況下覺(jué)得很慢，那么就不要怪Artemis。

并且Connection，Session，Producer，Consumer這些對(duì)象本身設(shè)計(jì)上是可以復(fù)用的。因此JmsTemplate的做法會(huì)大大降低性能，并且將大部分的時(shí)間都花在反復(fù)重建這些對(duì)象上。

Spring提供的Workaround

可以讓JmsTemplate使用SingleConnectionFactory避免頻繁創(chuàng)建Connection的問(wèn)題?；蛘咂渥宇?lèi)CachingConnectionFactory避免頻繁創(chuàng)建Connection，Session，Producer，Consumer的問(wèn)題。

JmsTemplate#sendAndReceive方法可以用來(lái)模擬RPC調(diào)用過(guò)程，內(nèi)部原理是：

A程序創(chuàng)建一個(gè)臨時(shí)Queue作為接受相應(yīng)的Queue

send一個(gè)Message到Queue，并在這個(gè)臨時(shí)Queue上等待結(jié)果

B程序consume了這個(gè)Message把結(jié)果send到那個(gè)臨時(shí)Queue

A接受到結(jié)果，把這個(gè)臨時(shí)Queue干掉

當(dāng)然整個(gè)過(guò)程中還包括前面提到的創(chuàng)建Connection，Session，Producer，Consumer的動(dòng)作。

不出所料，Artemis官方文檔也提到了，頻繁創(chuàng)建臨時(shí)Queue是一種anti-pattern，會(huì)大大影響性能。

使用@JmsListener注解可以很方便的用來(lái)consume消息，但它是同步而非異步，這個(gè)和官方文檔所說(shuō)的恰恰相反（關(guān)于sync/async consume消息的資料）。

Spring Boot的JmsAnnotationDrivenConfiguration默認(rèn)使用DefaultJmsListenerContainerFactory生成DefaultMessageListenerContainer ，而它的內(nèi)部原理是使用TaskExecutor發(fā)起多個(gè)線(xiàn)程同時(shí)從Queue中拉取消息，這也就是為什么Spring官方文檔里說(shuō)如果監(jiān)聽(tīng)的是Topic且concurrency > 1，那么可能會(huì)收到重復(fù)消息的原因。

DefaultMessageListenerContainer的javadoc中說(shuō)道：

Actual MessageListener execution happens in asynchronous work units which are created through Spring"s TaskExecutor abstraction

這里就有個(gè)矛盾，如果使用async的方式consume消息，那么只需給consumer設(shè)置MessageListener就行了，何必使用TaskExecutor呢？

一看代碼果然不出所料：

DefaultMessageListenerContainer#runcallinvokeListener

然后callAbstractPollingMessageListenerContainer#receiveAndExecute

然后calldoReceiveAndExecute

然后callreceiveMessage

然后callreceiveFromConsumer

然后callJmsDestinationAccessor#receiveFromConsumer這個(gè)方法調(diào)用了MessageConsumer#consume

也就是說(shuō)Spring只是使用一個(gè)或多個(gè)線(xiàn)程在不停的同步的consume消息而已。

雖然可以使用concurrency參數(shù)提高并發(fā)，但是多線(xiàn)程從Queue/Topic中consume消息的性能比javax.jms.MessageConsumer#setMessageListener的方法要低上很多。

有興趣的同學(xué)可以使用Artemis Example（下載地址）里的JMS Perf代碼做一下測(cè)試，它的測(cè)試代碼用的是javax.jms.MessageConsumer#setMessageListener的方式來(lái)consume消息的，在配置正確的情況下可以達(dá)到接近10w/s。至于使用MessageConsumer.receive的性能測(cè)試則留給同學(xué)自己做了。

還是之前提到的JmsAnnotationDrivenConfiguration，使用的DefaultJmsListenerContainerFactoryConfigurer默認(rèn)是把session設(shè)置為transacted的。

根據(jù)測(cè)算，當(dāng)一個(gè)session是transacted的時(shí)候其性能會(huì)相差20%，有興趣的同學(xué)可以使用Artemis Example（下載地址）里的JMS Perf代碼做一下測(cè)試。

下載之后找到examples/jms/perf目錄，看這個(gè)目錄下的readme.html獲得執(zhí)行方法，在執(zhí)行之前修改src/main/resources/perf.properties文件，下面是部分參數(shù)的解釋?zhuān)?/p>

num-messages，測(cè)試多少個(gè)消息

num-warmup-messages，熱身用的消息數(shù)，熱身過(guò)之后性能會(huì)提升

durable，對(duì)應(yīng)DeliveryMode

transacted，是否transacted

batch-size，批量commit的大小

drain-queue，是否測(cè)試前先把隊(duì)列里已有的消息都清空

可以使用以下兩套配置對(duì)比transacted的性能差別：

配置一，transacted=false：

num-messages=100000
num-warmup-messages=1000
message-size=1024
durable=false
transacted=false
batch-size=1
drain-queue=true
destination-lookup=perfQueue
connection-factory-lookup=/ConnectionFactory
throttle-rate=-1
dups-ok-acknowledge=false
disable-message-id=true
disable-message-timestamp=true

配置二，transacted=true：

num-messages=100000
num-warmup-messages=1000
message-size=1024
durable=false
transacted=true
batch-size=1
drain-queue=true
destination-lookup=perfQueue
connection-factory-lookup=/ConnectionFactory
throttle-rate=-1
dups-ok-acknowledge=false
disable-message-id=true
disable-message-timestamp=true

關(guān)于加入事務(wù)控制是否會(huì)有性能問(wèn)題沒(méi)有實(shí)際測(cè)試過(guò)，不過(guò)值得注意的這是Spring Boot的默認(rèn)行為。

相關(guān)連接：代碼1, 代碼2，代碼3，Javadoc。

Spring將JMS的集成變得非常簡(jiǎn)單，只需提供幾個(gè)配置參數(shù)就可以了，但是只能提供一種默認(rèn)配置，不管業(yè)務(wù)場(chǎng)景如何都使用同一種配置是非常有問(wèn)題的。

spring-boot提供了以下幾種方式（文檔）集成JMS：

JNDI

Artemis, native模式和embedded模式

ActiveMQ

這幾種模式的缺點(diǎn)都是只能配置一個(gè)ConnectionFactory，這對(duì)于簡(jiǎn)單應(yīng)用來(lái)說(shuō)沒(méi)問(wèn)題，對(duì)于復(fù)雜應(yīng)用來(lái)說(shuō)就顯得不夠用了，這讓你喪失了針對(duì)不同場(chǎng)景配置不同ConnectionFactory的機(jī)會(huì)。
而且Artemis的native模式只支持host:port，不支持更豐富參數(shù)的url模式。

看過(guò)DefaultJmsListenerContainerFactoryConfigurer和JmsAnnotationDrivenConfiguration的代碼就明白了。