用mq來將耗時比較長或者耗費資源的請求排隊，非同步處理，減輕伺服器壓力增加穩定性。
如果是高併發的實時請求，我個人覺得不適用這個方案。如果是為了高併發，我覺得應該朝解決高併發的方向考慮。集群、分布式、動靜分離、資料庫讀寫分離之類的。
web的話，只能客戶端頁面輪訓處理結果。
因為，據我個人了解啊，現在web沒有成熟的向客戶端推送處理結果的技術。或者是我沒弄好，如果有知道的，還望提點下。
把客戶行為變為非同步，就是提交後，只通知收到請求，需要客戶再提交查詢請求，檢視結果
首先，我們來說一下為什麼要使用mq（訊息佇列）？
主要原因是由於在高併發的環境下，由於伺服器來不及同步處理，請求往往會發生堵塞的現象，比如說大量的增加、修改（insert、
updata
）之類的請求同事到達
mysql
，直接導致無數的行鎖，表鎖、甚至最後請求堆積過多，從而觸發
too many connections
錯誤。通過使用訊息佇列
mq，我們就可以非同步處理請求，從而緩解系統的壓力。
訊息阻塞佇列現在比較流行的rabbitmq、
redismq
、activemq~
！也就是專業的
訊息中介軟體
，一般用於處理高併發的問題
~！這裡面
rabbitmq、
redismq
我沒有研究過，我只了解過
activemq~
！在activemq
中處理高併發問題時。我們首先就要知道是什麼的高併發。消費者，還是生產者。
首先，我來說一下消費者的高併發處理，因為這個簡單、好說一些~！它一般產生的原因是在
activemq
的佇列中積壓了資料的話，我們在
spring
中啟動了
listen
，但是（讀音重一點，停頓一下）
我們在activemq的監控網頁裡面看到只有乙個
consumer
（消費者）在執行，這時候就得說一說，
activemq
的執行機制了。它裡面也就是
activemq
是預設將 取
1000
條資料交由乙個
consumer
處理的，下乙個
1000
才是由另乙個去處理的。所以吧這個預設的值調一下就行了
~！一般我們是在客戶端的鏈結
url裡面，修改（
tcp://ipaddr:61616?jms.prefetchpolicy.all=2
），這樣就公平分配了~！
這時候我們來談一談怎麼去解決高併發的問題~！這裡就要說到部署
activemq
了，其實說白了就是擴充套件你的應用程式，我簡單的在網上查過一些資料，知道有差不多，大概有
3中處理方式。垂直擴充套件、橫向擴充套件、傳輸負載分流
1、垂直擴充套件
a) 垂直擴充套件簡單來說就是一種用於增加單個activemq**連線數的技術，這裡還得順便提一下，因為增加了**鏈結數，所有，他的負載能力也增強了。一般預設的情況下，
activemq
是使用的阻塞
io來處理傳輸鏈結的，也就是同步
io，乙個鏈結分配乙個執行緒，所有很明顯的，我們只需要吧同步
io換成非同步
io就行了，也就是非阻塞io（
nio）就行了，在
activemq
配置檔案中配置，至於具體的怎麼配的，我不太記得了，網上有資料~！
b) 除了同步io換非同步
io的方式。我們還可以根據每乙個客戶端的連線搞乙個訊息來分發執行緒，具體的好像是在系統引數
(org.apache.activemq.usededicatedtaskrunner)
設定為false
來設定activemq
使用將搞乙個執行緒池，不過用這個方法的話，有個前提，就是需要有足夠的記憶體來執行。這裡還有隱藏的乙個問題，就是
cpu的負載，就是如果你在使用
open-wire
協議的格式訊息。那麼最好是關閉
tight encoding
選項（這裡留個疑問給面試官。如果問，為什麼會占用cpu很多，和怎麼關
~！就答：
因為這個東西開啟的話，cpu占用就太多了，至於怎麼關，也是在系統引數檔案裡面配置）
2、橫向擴充套件
a) 垂直擴充套件是一種單獨的**
，第二個方式就是橫向擴充套件也就是我們所說的使用**網路來增加應用程式的**數量，它的原理就是利用網路自動傳遞訊息給所有網際網路的具有對訊息感興趣的消費者的**，所以，我們就可以配置客戶端鏈結到乙個**的集群，隨機的選擇集群中的乙個**來鏈結。（
這裡留個疑問給面試官。如果問怎麼弄？
就回答：網際網路嘛，我們通過url的引數配置就行了。）
3、傳輸負載分流
a) 而關於第三個方法，客戶端的傳輸負載分流，就是前面兩個（垂直和水平）的混合負載分流的方案，但是這裡通常不適用**網路，因為客戶端程式會決定將哪個負載傳送到哪個**上、客戶端程式需要維護多個jms鏈結，並且決定哪個
jms連線應該用於哪個訊息的目的地。
b) 這裡有乙個好處，就是由於沒有直接使用網路連線，我們就降低了**過量的訊息**，不需要進行額外的負載均衡處理。
詳細的文章)
高併發之訊息佇列
比如乙個介面處理簡訊傳送，如果沒處理完就可以放入訊息佇列 然後等待介面處理，如果介面處理簡訊傳送失敗則可以再次放入訊息佇列，減少嘗試的次數和占用的執行緒，再次進行處理。舉幾個例子 業務系統觸發簡訊傳送申請，但簡訊傳送模組速度跟不上，需要將來不及處理的訊息暫存一下，緩衝壓力。就可以把簡訊傳送申請丟到訊...
高併發系統設計 訊息佇列
該文章記錄極客時間 高併發系統設計 系列文章的相關知識點，供以後自己檢視。這篇文章主要介紹一下訊息佇列的使用。訊息佇列一般有以下作用 非同步處理 解耦合和削峰填谷。訊息佇列可能存在訊息丟失的情況，如何防止訊息丟失以及在訊息重複的場景，如何保證盡量不影響訊息最終的處理結果。訊息的丟失可以通過生產端的重...
高併發場景 多執行緒，訊息佇列應用
高併發產生的應用場景 在同時很多人同時訪問乙個業務一樣。例如很多人都想上廁所但是只有乙個廁所，每次只能就去乙個人乙個人結束後另乙個人才能上廁所這個屬於單執行緒產生的效果 以上兩種場景唯一不變的是廁所每次只有一人能進行，還有上廁所的人，變的是廁所變多了 訊息佇列 訊息佇列相當於將上廁所的每個人都加入到...