消息中間件的意義和應用場景 （activeMq）

消息中間件通常兩個功能,解耦和異步處理,分別舉個例子吧

解耦合:
好比咱們作一個微博產品中的好友系統,就很須要使用消息中間件
當咱們添加一個關注的時候, 涉及如下幾個子系統

推薦系統,須要根據你關注的人給你作數據分析
搜索系統,須要根據你的數據創建索引
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