最近，項目中使用到了ActiveMQ獲取第三方推送過來的數(shù)據(jù)。具體背景是：公司需要監(jiān)控全國各地車輛實時運行的GPS數(shù)據(jù)，但監(jiān)控本身不是公司做的，而是交給第三方公司做，第三方采集GPS數(shù)據(jù)后推送給我們。全國各地，近萬臺車輛，每臺車輛每隔幾秒就發(fā)送一次GPS位置數(shù)據(jù)，如果我們提供API給第三方公司去調用，顯然無論是第三方還是我們這邊，服務器都是是扛不住的，這么做也是不合理的，于是，便采取了消息隊列，第三方采集到的數(shù)據(jù)直接推送到消息隊列代理服務器，而己方從消息隊列服務器取數(shù)據(jù)處理。以下對項目實踐及其中遇到的一些問題及解決進行概要總結。
1、ActiveMQ NMS簡介
關于NMS，這里主要談兩點。
NMS API：ActiveMQ定義的一套API接口規(guī)范，你可以理解為一個API的接口，它指明了生產者或消費者如何與消息隊列服務器通信。
NMS Providers：NMS API的具體實現(xiàn)，基于Windows或ActiveMQ下的各種協(xié)議，提供了各種實現(xiàn)，目前提供了ActiveMQ、STOMP、MSMQ、EMS、WCF、AMQP、MQTT、XMS幾種實現(xiàn)。具體項目中，我采取的是ActiveMQ實現(xiàn)。
至于消息隊列涉及到的其他概念，什么Broker、Queue、Topic、Producer、Consumer，這里不做介紹，各位可以自己查資料，這些 概念本身也不難理解的。
2、關于異常下的Broker重連
這個異常，可能是由于網(wǎng)絡異常，也可能是長時間沒有通信，Broker把Client給斷掉了，不去管它。起初，這個項目是從一位離職員工的手頭接過來的，給的說法是只需要維護就夠了，基本上不用調整。當時雖然說是做了重連，后來發(fā)現(xiàn)，就跟沒做一樣。發(fā)現(xiàn)這個，是起源于第三方頻繁通知，MQ隊列有積壓，通知我們盡快處理。項目拿到手一看，我勒個去，直接起了一個Timer在那兒定時監(jiān)控Connection狀態(tài)，如果狀態(tài)不對立刻重新打開連接。先不說Socket連接的浪費情況，及Timer這個.NET中近乎Bug的一個東西，這種做法實際中行之無效，因為連接異常情況
