什麼時候使用MQ
【典型場景一：數據驅動的任務依賴】
什麼是任務依賴，舉個栗子，互聯網公司經常在凌晨進行一些數據統計任務，這些任務之間有一定的依賴關係，比如：
1）task3需要使用task2的輸出作爲輸入
2）task2需要使用task1的輸出作爲輸入
這樣的話，tast1,
task2,
task3之間就有任務依賴關係，必須task1先執行，再task2執行，載task3執行。
優化方案是，採用MQ解耦：
1）task1準時開始，結束後發一個“task1
done”的消息
2）task2訂閱“task1
done”的消息，收到消息後第一時間啓動執行，結束後發一個“task2
done”的消息
3）task3同理
採用MQ的優點是：
1）不需要預留buffer，上游任務執行完，下游任務總會在第一時間被執行
2）依賴多個任務，被多個任務依賴都很好處理，只需要訂閱相關消息即可
3）有任務執行時間變化，下游任務都不需要調整執行時間
需要特別說明的是，MQ只用來傳遞上游任務執行完成的消息，並不用於傳遞真正的輸入輸出數據。
【典型場景二：上游不關心執行結果】
上游需要關注執行結果時要用“調用”，上游不關注執行結果時，就可以使用MQ了。
舉個栗子，58同城的很多下游需要關注“用戶發佈帖子”這個事件，比如招聘用戶發佈帖子後，招聘業務要獎勵58豆，房產用戶發佈帖子後，房產業務要送2個置頂，二手用戶發佈帖子後，二手業務要修改用戶統計數據。
優化方案是，採用MQ解耦：
1）帖子發佈成功後，向MQ發一個消息
2）哪個下游關注“帖子發佈成功”的消息，主動去MQ訂閱
採用MQ的優點是：
1）上游執行時間短
2）上下游邏輯
物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴
3）新增一個下游消息關注方，上游不需要修改任何代碼
典型場景三：上游關注執行結果，但執行時間很長
有時候上游需要關注執行結果，但執行結果時間很長（典型的是調用離線處理，或者跨公網調用），也經常使用回調網關
MQ來解耦。
舉個栗子，微信支付，跨公網調用微信的接口，執行時間會比較長，但調用方又非常關注執行結果，此時一般怎麼玩呢？
一般採用“回調網關
MQ”方案來解耦：
1）調用方直接跨公網調用微信接口
2）微信返回調用成功，此時並不代表返回成功
3）微信執行完成後，回調統一網關
4）網關將返回結果通知MQ
5）請求方收到結果通知
這裏需要注意的是，不應該由回調網關來調用上游來通知結果，如果是這樣的話，每次新增調用方，回調網關都需要修改代碼，仍然會反向依賴，使用回調網關
MQ的方案，新增任何對微信支付的調用，都不需要修改代碼啦。
五、總結
MQ是一個互聯網架構中常見的解耦利器。
什麼時候不使用MQ？
上游實時關注執行結果
什麼時候使用MQ？
1）數據驅動的任務依賴
2）上游不關心多下游執行結果
3）異步返回執行時間長