消息中间件一般两个功能,解耦和异步处理,分别举个例子吧
解耦合:
比如我们做一个微博产品中的好友系统,就很需要使用消息中间件
当我们添加一个关注的时候, 涉及以下几个子系统
推荐系统,需要根据你关注的人给你做数据分析
搜索系统,需要根据你的数据建立索引
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