消息中間件一般兩個功能,解耦和異步處理,分別舉個例子吧
解耦合:
比如我們做一個微博產品中的好友系統,就很需要使用消息中間件
當我們添加一個關注的時候, 涉及以下幾個子系統
推薦系統,需要根據你關注的人給你做數據分析
搜索系統,需要根據你的數據建立索引
feed系統,需要根據你關注的人,發送一條新鮮事
統計系統 用於數據統計,了解產品情況
而如果直接在加關注的流程里進行這些操作,可能帶來風險,所以,會引入mq來解耦合,因此就像你說的,一般是 "單向傳輸" 的(當然這不是絕對的,取決於你系統復雜度),而且發往mq的數據一般都不大,比如 from_uid, to_uid 就行了,一般都不會很大,如果發送的數據不滿足你的要求,這個時候,需要調用好友系統提供的接口了
異步處理:
有的時候,我們一個操作可能會耗時比較久,所以,並不會在主要業務流程里進行處理
比如,我們在刪除一個用戶的時候,可能會有很多關聯數據的操作,為了盡快的響應以及解耦合,我們會將這個消息發送給其他系統,讓它們根據需求自己處理
轉自：http://blog.sina.com.cn/s/blog_7085382f0102uy79.html
場景
1.分布式系統中，不同系統之間傳遞消息。
比如系統B要監聽系統A的消息，當A發出消息的時候，系統B根據消息，做相應的變化。這個場景很容易理解，就是不同系統之間的異步交互。
2.在系統A中，自己發消息，自己監聽。這個場景是我在現在工作中遇見的，當時看到自己的系統監聽消息，下意識就想，是哪個系統發送的消息呢？后來問了別人才知道，是自己系統發消息，自己監聽。為什么要這樣做，自己系統中，直接可以調用到自己內部的一些方法了呀？原來這樣做的原因有如下，首先，發送消息可以實現異步做一些動作，比如我們對一些信息做了修改，這些信息要同步到另一個系統中，我們有一種方法是，在一個事務里，做完修改就立刻調用另一個系統的modify方法，但是這樣有一個問題，如果這個事務中很多方法，很可能導致調用超時，或者我們這一個方法體中，有多個調用，會導致系統耦合性太強，如果我們通過發送消息的方式調用，就做到了在本方法體中減少了方法調用，調用移動到了消息監聽者中。這樣不僅方法體中調用減少，而且做到了松耦合。
轉自：http://blog.csdn.net/u012814506/article/details/48303071