What

消息系統(tǒng)是一種跨進程的通信機制，用于上下游傳遞消息的。

Why

使用了MQ后，消息發(fā)送上游只需要依賴MQ，不需要在依賴其他服務了。

When

1. 數(shù)據(jù)驅(qū)動的任務依賴
   比如：系統(tǒng)經(jīng)常需要在凌晨做一些數(shù)據(jù)統(tǒng)計的任務，這些任務之間有一定的依賴性。比如說我要先歸檔，然后在統(tǒng)計完各個類別有多少個案件數(shù)，然后用這個案件數(shù)來做下一步的統(tǒng)計...，這樣多個任務之間有個順序的依賴關系。
   這種情況下我們可以使用MQ來解耦，每個任務執(zhí)行結束后都發(fā)一個消息，告訴其他任務我這邊結束了，你可以開始了。
   可以用來做這種通知的，多個任務之間只需要依賴MQ即可
   其實這種情況也可以開個接口，但這樣可能會導致服務之間，系統(tǒng)之間耦合度比較高。

2. 上游不需要關心你下游執(zhí)行的結果
   上游只管發(fā)消息就好了，你這個消息后面是怎么被消費的，是怎么被下游使用的我上游是不怎么太關心的。也可以說是不需要適時性那么高。
   比如：在案件信息有變動的時候需要給當事人發(fā)短信，但實際上我們可能不需要太關心短信是否適時的正確發(fā)送了。
   采用這種方案的優(yōu)點是：

   1. 上游執(zhí)行時間短
   2. 邏輯解耦，除了依賴mq，其他互不依賴
   3. 如果需要新增一個下游的功能，上游不需要修改代碼，只需要新加的這個下游服務訂閱上游即可

3. 上游比較關注執(zhí)行的結果，但是執(zhí)行時間比較長
   有時候執(zhí)行執(zhí)行很長，而且我們還需要等待。這時候我們要關注結果我們該怎么辦呢？
   舉個栗子：在調(diào)用微信支付，我們會調(diào)用微信的接口，但是執(zhí)行時間會比較長。這個是時候微信會立即返回一個調(diào)用成功的消息，然后微信執(zhí)行完了，付款成功就往MQ發(fā)個消息。然后上游訂閱這個消息就可以知道付款到底是成功還是沒有成功，沒有成功的話可能需要重試之類的操作。

NO WHEN （不需要使用MQ的場景）

MQ這么好那我們什么場景都要用MQ嗎？
不是的，在那種調(diào)用和被調(diào)用的關系中我們是無法用MQ來取代的。
MQ有哪些缺點：

1. 多加了一個組件
2. 消息路徑更長了
3. 要同時保證消息不丟失和消息不重復很難
4. 上游不知道下游執(zhí)行的結果