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

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

2018年8月份，突然有一天前面傳來噩耗，用戶注冊后沒收到積分，這真是迎頭一棒啊。但是，我不能因為一次打擊就失去對Artemis的信任，于是對整個模塊進行了代碼分析，結果發現代碼沒問題，妥妥的！

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

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

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

這個節點上沒有Consumer連接為什么producer還一直發送消息呢？

正常情況下有Consumer才會把消息發送到該節點上的。這在測試環境上是不存在的，而且沒有consumer有消息過來正常情況也應該redistribute到其他節點的，所以

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

于是我做了以下兩種調整：

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

打開文件 /etc/sysctl.conf，編輯文件，加入以下內容：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 30

然后執行 /sbin/sysctl -p 讓參數生效。

修改Artemis集群方式

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

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

這就完美了嗎？NO！又發現新問題了。

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

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

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

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

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

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

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

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