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

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

2018年8月份，突然有一天前面?zhèn)鱽碡?，用戶注冊后沒收到積分，這真是迎頭一棒啊。但是，我不能因為一次打擊就失去對Artemis的信任，于是對整個模塊進行了代碼分析，結(jié)果發(fā)現(xiàn)代碼沒問題，妥妥的！

查看Artemis控制臺，發(fā)現(xiàn)有很多未消費的消息，之前一個多月都沒有問題，都未出現(xiàn)過未消費的消息，就中間做過一次升級上線。

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

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

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

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

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

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

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

打開文件 /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集群方式。

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

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

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

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

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

一種是輪詢，這種適合性能要求比較高的場景，提高消費效率的。

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

一種是只取第一個節(jié)點，這種適合做雙機熱備的場景。

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

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