MQ

消息中间件概述

marksugar
2016-12-04 / 0 评论 / 3,079 阅读 / 正在检测是否收录...
温馨提示:
本文最后更新于2016年12月04日,已超过1825天没有更新,若内容或图片失效,请留言反馈。

消息中间件特点:

1,异步处理模式
消息发送者可以发送一个消息而无需等待响应,消息发送者将消息发送到一条虚拟的通道或队列上,消息接收者则订阅或监听该通道,一条消息可能最终转发给一个或多个消息接受者,这些接受者都无需对消息发送者做出同步回应,整个过程是异步的,如:用户注册
2,应用程序和应用程序调用关系为松耦合关系,发送者和接受者不必了解对方,只需要确认消息,发送者和接受者不必同时在线
比如在线交易系统为了保证数据一致性,在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态,两个系统通过消息中间件解耦
消息传递服务模型,如下图:
1.png

消息中间件传递模型

1,点对点模型PTP

点对点模型用于消息生产者和消息消费者之间点对点的通信,消息生产者将消息发送到由某个名字标示的特定消费者,此名字实际上对应消息服务中的一个队列queue,在消息传递给消费者之前他被存储在这个队列中,队列消息可以放在内存中也可以是持久的,以保障消息服务出现故障时仍然能够传递消息

1.1 模型特性:

每个消息只有一个消费者,发送者和消费者没有时间依赖,接受者确认消息接受和处理成功,如下图:
2.png

2,发布订阅模型PUB/SUB

发布者/订阅者模型支持向一个特定的消息主题生产消息,0或多个订阅者可能对接收来自特定消息主题的消息敢兴趣,在这种模型下,发布者和订阅者彼此不知道对方,这种模式好比匿名公告,这种模式被概括为:多个消费者可以获得消息,在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅subscription,以便能够消费者订阅。订阅者必须保持持续的活动状态用来接收消息,除非订阅者建立了持久订阅,在这种情况下,在订阅者未连接时发布的消息在订阅者重新连接时重新发布

2.1 发布订阅模型特性

1,每个消息有多个订阅者
2,客户端只有订阅后才能接受到消息
如下图,当有消息更新后会同时更新订阅者,并且一个消息会有多个订阅者,如下图:
3.png
3,持久订阅和非持久订阅
如下图,如果此时持久订阅出现故障,在故障后重启则会重新发送一次消息,如果非持久订阅则不会,消息则错过,如下图:
4.png
消费者订阅后,中间件会投递给消费者,消费者确认后在返回给中间件,如下图:
5.png
1,发布者和订阅者是存在时间以来的,当接受者和发布者只有建立订阅关系才能收到消息。当订阅关系建立后,消息就不会丢失,不管订阅者是否都在线。
当订阅者接受了消息,必须一直在线,当只有一个订阅者时约等于点对点模式,如一个消息中间件分为多个块,如下图:
6.png

场景

异步处理

1,用户注册

用户注册,成功会发生邮件或短信
当正常情况下回发生成功,如果在期间发生网络抖动或者服务意外停止,则可能需要消息超时机制,在或者重试机制,如下图:
7.png

2,日志分析

使用案例,计算pv和用户行为分析,订阅模式,如下图:
8.png

3,数据复制

数据从源复制到多个目的地,一般要求保持数据一致性,顺序或者保证因果序列。用于跨机房数据传输,搜索,离线数据计算等,如下图:
9.png

4,延迟消息发送和暂存

把消息中间件当成可靠的消息暂存地,定时进行消息投递,比如模拟用户秒杀等做习题压测,如下图:
10.png

5,消息广播

缓存数据同步更新,应用推送数据,比如更新本地缓存,如下图:
11.png

消息中间件分类

消息中间件主要分为push和 pull
push推消息模型,消息生产者将消息发送给消息传递服务,消息传递服务又将消息推送给消息消费者
pull拉取消息模型,消费者请求消息服务接收消息,消息生产者从消息中间件拉取消息
在一般场景中,消费者拉取更容易控制,如果是生产者推送给消费者的话,需要提供更多的处理,如负载均衡,后端订阅者信息收集的集群等,显而易见,拉取则更容易控制范围,但是,拉取通常可能一次拉取成千上百万的数据,这时,数据存储设备和带宽也是必备考量的环节,#原文链接www#linu#xea#com/1506.html#,类似注册用户发送短信这种实时的信息则不适用于拉取,更偏向于推送,对比如下图:
12.png

0

评论 (0)

取消