摘要：通過(guò)以上修改保證了客戶端連接能夠快速的斷開(kāi)，在應(yīng)用重啟時(shí)不會(huì)持續(xù)往這邊發(fā)送消息，我使用進(jìn)行壓測(cè)，重啟消費(fèi)者過(guò)程中，消息都正常。

2018年6月份，我們開(kāi)發(fā)了兩個(gè)使用Artemis做消息隊(duì)列實(shí)現(xiàn)的積分模塊和PUSH推送模塊，在幾輪測(cè)試以后，大家信心滿滿的正式上線了，而且經(jīng)過(guò)了一個(gè)多月使用，一切都很順利，感覺(jué)生活一切都美美的。

2018年8月份，突然有一天前面?zhèn)鱽?lái)噩耗，用戶注冊(cè)后沒(méi)收到積分，這真是迎頭一棒啊。但是，我不能因?yàn)橐淮未驌艟褪?duì)Artemis的信任，于是對(duì)整個(gè)模塊進(jìn)行了代碼分析，結(jié)果發(fā)現(xiàn)代碼沒(méi)問(wèn)題，妥妥的！

查看Artemis控制臺(tái)，發(fā)現(xiàn)有很多未消費(fèi)的消息，之前一個(gè)多月都沒(méi)有問(wèn)題，都未出現(xiàn)過(guò)未消費(fèi)的消息，就中間做過(guò)一次升級(jí)上線。

通過(guò)仔細(xì)慎重的分析所有的證據(jù)，我斷定這是一次重啟引發(fā)的“血案”！

如果在某一個(gè)Artemis節(jié)點(diǎn)上有很多未消費(fèi)的消息，而且還在增多，那么只有一個(gè)可能，這個(gè)節(jié)點(diǎn)上沒(méi)有consumer連接，而且這個(gè)節(jié)點(diǎn)上的消息不能redistribute到其他節(jié)點(diǎn)上，既然這樣問(wèn)題就很清楚了。

這個(gè)節(jié)點(diǎn)上沒(méi)有Consumer連接為什么producer還一直發(fā)送消息呢？

正常情況下有Consumer才會(huì)把消息發(fā)送到該節(jié)點(diǎn)上的。這在測(cè)試環(huán)境上是不存在的，而且沒(méi)有consumer有消息過(guò)來(lái)正常情況也應(yīng)該redistribute到其他節(jié)點(diǎn)的，所以

我推測(cè)是Artemis的集群出了問(wèn)題了，而且查看Artemis生產(chǎn)環(huán)境下鏈接到61616端口的鏈接TIME_WAIT的較多。

于是我做了以下兩種調(diào)整：

修改linux的網(wǎng)絡(luò)配置，減少TIME_WAIT連接，減少斷開(kāi)的識(shí)別時(shí)間。具體操作步驟如下：

打開(kāi)文件 /etc/sysctl.conf，編輯文件，加入以下內(nèi)容：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 30

然后執(zhí)行 /sbin/sysctl -p 讓參數(shù)生效。

修改Artemis集群方式

我把Artemis的集群由UDP改為了static集群方式。

通過(guò)以上修改保證了客戶端連接能夠快速的斷開(kāi)，在應(yīng)用重啟時(shí)不會(huì)持續(xù)往這邊發(fā)送消息，我使用jmeter進(jìn)行壓測(cè)，重啟消費(fèi)者過(guò)程中，消息redistribute都正常。

這就完美了嗎？NO！又發(fā)現(xiàn)新問(wèn)題了。

在50個(gè)線程壓測(cè)時(shí)進(jìn)行重啟應(yīng)用，雖然重啟后消息消費(fèi)和redistribute正常，但是在重啟的那一瞬間，在使用ON_DEMAND模式下節(jié)點(diǎn)上消費(fèi)者斷開(kāi)的一瞬間服務(wù)器判斷有一部分延遲，還是有一部分的消息發(fā)送到了沒(méi)有consumer的節(jié)點(diǎn)上，這些消費(fèi)者不能再被redistribute，這可能是Artemis的一個(gè)bug。

怎么辦呢？為什么應(yīng)用只能連接到一個(gè)節(jié)點(diǎn)上呢？這也不能說(shuō)是spring-jms的一個(gè)坑，還是對(duì)spring-jms不夠數(shù)量，spring-jms在創(chuàng)建消費(fèi)監(jiān)聽(tīng)的時(shí)候，無(wú)論有多少個(gè)Session，都只會(huì)創(chuàng)建一個(gè)共享連接，無(wú)論你有多少個(gè)Artemis節(jié)點(diǎn)，一個(gè)應(yīng)用就永遠(yuǎn)只會(huì)連到一個(gè)節(jié)點(diǎn)，這真是大大的浪費(fèi)呀。這個(gè)真是SpringJms的坑。

難道Artemis真的就這么差嗎？實(shí)際上我看了Artemis自帶的客戶端以后，發(fā)現(xiàn)其實(shí)它在創(chuàng)建連接時(shí)自帶三種策略，

一種是輪詢，這種適合性能要求比較高的場(chǎng)景，提高消費(fèi)效率的。

一種是隨機(jī)，隨便選一個(gè)節(jié)點(diǎn)連上就可以了，不知道為什么有這種策略。

一種是只取第一個(gè)節(jié)點(diǎn)，這種適合做雙機(jī)熱備的場(chǎng)景。

因此這個(gè)SpringJms帶的坑，還得自己填，使用自帶client進(jìn)行創(chuàng)建消費(fèi)者監(jiān)聽(tīng)，這樣的情況下，只要最大連接數(shù)超過(guò)2個(gè)以上，通過(guò)輪詢的方式創(chuàng)建連接，就會(huì)平均創(chuàng)建到多個(gè)節(jié)點(diǎn)上，即使重啟過(guò)程中有幾個(gè)消息不能redistribute重啟以后有消費(fèi)者連接上來(lái)就能繼續(xù)消費(fèi)。

好吧，大功告成，生活終于又美好了。