MQ與webservice的差別，MQ的差別

Webservice 和MQ(MessageQueue)都是解決跨平台通信的常用手段，兩者有哪些差別呢？

個人認為最本質的差別在于 Webservice近乎實時通信，而MQ卻通常是延時通信。

什麼意思呢？

因為webservice其實就是本地伺服器程式調用遠端伺服器上的方法，屬于兩者之間的互動，請求的時候需要等被請求的伺服器做出回應後，另一端才會有所動作，也就是說，如果你請求的service伺服器關閉了，或者中斷了，那麼你這邊肯定就得不到答複了，你的這次請求就算是打水漂丢失了。

而MQ 則相當于是多了一個中間件

我所發送的請求 都必須先傳達給 這個消息隊列元件，然後由這個消息隊列元件再去到另一個伺服器上去請求，有了響應之後再 傳回給

當初的請求程式，因為MessageQueue元件會把消息持久化放在本地，是以哪怕突然當機了，請求消息也是不會丢失的。

比如我們有些複雜的生成報表的請求，生成一張報表可能會相當繁雜，要這麼幾分鐘，那我們肯定不可能在那幹等，這時候就使用MQ，按這個請求報表的需求傳給MQ,等到接收程式處理完傳回之後，我這邊會收到通知，這樣就比較好。

常見的MQ元件 包括MSMQ ,Apache ActiveMQ以及一些開源mq等。

MQ的作用是削峰和解耦？

MQ最大的好處就是削峰和解耦，在RPC式的同步調用場景中，

如果同一個邏輯中調用A和B，那麼在擴充的時候，A和B一定是需要同時擴充的，但是有了消息以後，A發送消息給B，及時B暫時處理不了，

也可以等到A峰值過後B繼續處理，即使B短期無法比對A的發送消息能力也沒有關系。

削峰的應用場景：

流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導緻流量暴增，應用挂掉。為解決這個問題，一般需要在應用前端加入消息隊列。
a、可以控制活動的人數
b、可以緩解短時間内高流量壓垮應用

使用者的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接抛棄使用者請求或跳轉到錯誤頁面。
秒殺業務根據消息隊列中的請求資訊，再做後續處理

2.4日志處理
日志處理是指将消息隊列用在日志進行中，比如Kafka的應用，解決大量日志傳輸的問題。架構簡化如下

日志采集用戶端，負責日志資料采集，定時寫受寫入Kafka隊列
Kafka消息隊列，負責日志資料的接收，存儲和轉發
日志處理應用：訂閱并消費kafka隊列中的日志資料 

2.5消息通訊
消息通訊是指，消息隊列一般都内置了高效的通信機制，是以也可以用在純的消息通訊。比如實作點對點消息隊列，或者聊天室等
點對點通訊：

用戶端A和用戶端B使用同一隊列，進行消息通訊。

聊天室通訊：

用戶端A，用戶端B，用戶端N訂閱同一主題，進行消息釋出和接收。實作類似聊天室效果。      

解耦的應用場景：

應用解耦
場景說明：使用者下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。如下圖：

傳統模式的缺點：假如庫存系統無法通路，則訂單減庫存将失敗，進而導緻訂單失敗，訂單系統與庫存系統耦合

如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：

訂單系統：使用者下單後，訂單系統完成持久化處理，将消息寫入消息隊列，傳回使用者訂單下單成功
庫存系統：訂閱下單的消息，采用拉/推的方式，擷取下單資訊，庫存系統根據下單資訊，進行庫存操作
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。      

實作訂單系統與庫存系統的應用解耦