上個(gè)月記錄了一下集群消息轉(zhuǎn)發(fā)問題的現(xiàn)象：
假設(shè) Client_A連接MQ_A，消費(fèi)TOPIC_A巾兆。消息下發(fā)時(shí)，出現(xiàn)Client_A接收不到消息的情況虎囚。
- Client_A連接的MQ_A上只有這個(gè)Client_A一個(gè)消費(fèi)者消費(fèi)TOPIC_A上的消息角塑。
- 查看TOPIC的訂閱者信息，除了Client_A外淘讥，還可能出現(xiàn)該MQ轉(zhuǎn)發(fā)到其他MQ上的虛擬消費(fèi)者圃伶，表示發(fā)到這個(gè)TOPIC的消息需要被轉(zhuǎn)發(fā)給其他MQ
- 集群內(nèi)其他所有MQ上的TOPIC_A上查看訂閱者，均未出現(xiàn)類似的虛擬消費(fèi)者，表示消息不會(huì)被轉(zhuǎn)發(fā)到MQ_A窒朋，所以Client_A無法收到消息搀罢。
- 重啟Client，Client會(huì)自動(dòng)飄到集群內(nèi)其他的MQ上炼邀，此時(shí)可以正常消費(fèi)魄揉。
- 指定MQ_A要求Client_A重啟后連接到MQ_A，也可以正常消費(fèi)拭宁。
最近開始嘗試解決這個(gè)問題。一開始還是需要再深挖一下原因瓣俯，于是我修改了一下DemandForwardBridgeSupport這個(gè)類杰标，加了一些日志來觀察集群消費(fèi)者建立的過程。這個(gè)類的主要作用就是負(fù)責(zé)建立集群之間的訂閱彩匕，當(dāng)消費(fèi)者連接到集群中某臺(tái)MQ后腔剂，該臺(tái)MQ會(huì)發(fā)送一個(gè)advisory message給集群內(nèi)其他的MQ。
在修改源碼增加日志后發(fā)現(xiàn)驼仪，當(dāng)集群負(fù)載增加時(shí)掸犬，會(huì)出現(xiàn)advisory message沒有被集群中部分MQ收到的現(xiàn)象。比如集群中8臺(tái)MQ绪爸，當(dāng)消費(fèi)者建立連接到一臺(tái)MQ時(shí)湾碎，集群中有4臺(tái)MQ收到advisory message，有3臺(tái)沒有收到奠货，可是生產(chǎn)者往往就連接在那沒收到的3臺(tái)MQ上（墨菲定律T_T）介褥，導(dǎo)致了集群轉(zhuǎn)發(fā)的異常。
這個(gè)問題出現(xiàn)的場(chǎng)景一般是大量客戶端與集群建立連接時(shí)递惋。在官方JIRA上提了這個(gè)BUG柔滔，他們建議我升級(jí)到最新版本5.15試試，如果還出現(xiàn)他們?cè)倏? =
于是我今晚把一整套環(huán)境升級(jí)到5.15版本萍虽，然后再次嘗試了一下睛廊。雖然看源碼發(fā)現(xiàn)已經(jīng)有了一些優(yōu)化，但是問題仍然存在杉编。
由于在DemanForwardBridgeSupport中采用的是監(jiān)聽器的方式（Listener）超全，advisory message消息確認(rèn)有從源頭發(fā)出（集群中有MQ收到），那可能的原因應(yīng)該是監(jiān)聽器所在的連接的異常王财，但是再往下挖水就太深了……
利用已有的能力卵迂，我暫時(shí)想到了幾個(gè)方法：
- 將networkTTL設(shè)置為2。這樣消息就可以支持被轉(zhuǎn)發(fā)經(jīng)過兩個(gè)MQ Broker绒净。也就是說Producer->A->B->C->Consumer见咒。雖然中間多經(jīng)過一層，但是如果能保證消息的可靠性挂疆，犧牲一點(diǎn)性能還是可以允許的改览。
- 修改源碼下翎，自己增加一個(gè)機(jī)制判斷，如果advisory message被漏了宝当，則建立一個(gè)多層的傳輸通道视事。
- 修改源碼，每來一個(gè)consumer庆揩，則發(fā)多條advisory message俐东，保證集群中所有MQ都收到。
- 提BUG給ACTIVEMQ JIRA订晌。虏辫。。锈拨。
- 為MQ增加一個(gè)插件砌庄，插件訪問一個(gè)共享文件系統(tǒng)或者緩存，通過遍歷消費(fèi)者和其所連接的MQ的方式來發(fā)現(xiàn)沒有被正常建立的集群連接奕枢，發(fā)現(xiàn)后重啟AGENT娄昆。
每一個(gè)都是耗時(shí)巨大的工程……
