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