很榮幸，原來一直聽說的訊息佇列終於在前段時間用到了自己的專案中。為什麼會用到訊息佇列？毫無疑問，當然是傳輸訊息。
這裡訊息一般是一串字串，當然，訊息的含義很多，可以是「hello world」，可以是「你吃飯了嗎？」，可以是一串正式的xml報文。
也可以是乙個txt檔案或者xml檔案(在用active mq的時候可以直接傳輸檔案，active mq自帶傳輸服務，有自己的傳輸目錄，傳輸的格式為blogmessage)。
廢話不多說，先描述下業務場景：
我們的系統a要跟另乙個系統b（這個系統有訊息佇列b）之間互相傳輸資料，利用訊息佇列c中轉，我們每天會向c佇列發出訊息，他們接收資料然後給b佇列（交易量可能會比較大）；b佇列再將返回的訊息給c佇列，再回到我們的系統。
當然，前面的博文中說到了傳輸訊息的方式有很多，webservice方式，兩個系統esb用不到了，
而且業務場景比較簡單，主要就是為了滿足高併發的情況下，兩個系統之間能夠正常並且準確通訊的問題。所以用到了訊息佇列。
大致流程如下：
應用程式與佇列管理器連線。它通過 mqconnect 來進行此連線。下一步呼叫 mqopen 為輸出開啟乙個佇列。
然後應用程式呼叫mqput 將其資料放到佇列上。要接收資料，應用程式呼叫 mqopen 開啟輸入佇列。應用程式呼叫mqget 從佇列上接收資料。
本地的報文訊息以流的方式傳輸到佇列c，c再給b，b再給c，然後a系統接收c返回的訊息。
實現過程乙個注意的地方：傳送訊息時，定義乙個message_id，對方會將你的message_id處理一下，應該是複製到correlation_id中，然後收訊息時，一定將correlation_id再複製到message_id，這樣可以確保高併發情況下你發出去的訊息能收到對應的返回訊息。不然的話高併發情況你發的a報文不一定能拿到a_back.xml。
題外話：
在平時的開發中，我認為正確的思路很重要，需求來了，一定要先分析，最好是紙筆在紙上寫一寫，把要做的功能弄清楚，
思想很重要，一定是先構思。上次寫的那個跟esb聯調的，我收到的需求是提供乙個webservice服務，讓別人查我們的庫然後
把資料送給他們，我已經寫好了介面**都上測試環境了，結果說是有esb中轉這麼一回事，而且第三方系統跟我們系統報文的格式
都不一致。最後我才明白其實就是esb跟我互動，我不管第三方系統，我接受的是乙個httprequest（esb用httprequest請求我的），
所以我直接在本地寫好乙個servlet接受訪問就行了。
開發中最難的一定不是寫**。設計很重要。各位，晚安。
訊息佇列MQ
目錄 一 簡介 二 為什麼需要訊息佇列 mq 三 介紹 訊息佇列 message queuing 在電腦科學中，是一種程序間通訊或同一程序間不同執行緒的通訊方式。廣義上講訊息佇列是解決分布式系統中，各個功能模組間的資訊傳遞通訊方式。與檔案傳輸和rpc相比，訊息佇列具有更好的平台無關性，並能夠很好地支...
MQ訊息佇列
1.解耦 系統a將userid寫到訊息佇列中，系統c和系統d從訊息佇列中拿資料。這樣有什麼好處？系統a只負責把資料寫到佇列中，誰想要或不想要這個資料 訊息 系統a一點都不關心。即便現在系統d不想要userid這個資料了，系統b又突然想要userid這個資料了，都跟系統a無關，系統a一點 都不用改。系...
訊息佇列MQ簡介
專案中要用到rabbitmq，領導讓我先了解一下。在之前的公司中，用到過訊息佇列mq，阿里的那款rocketmq，當時公司也做了簡單的技術分享，自己也看了一些部落格。自己在有道雲筆記上，做了一些整理，但後來也就擱在那了。現在有時間，就對mq的一些簡單的概念做下整理吧。rabbitmq的一些介紹，請參...