mq 订阅
MQ(Message Queue)消息队列,是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。 展开全文
MQ(Message Queue)消息队列,是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。
信息
提    供
强大、 安全、 稳定的消息数据传递
外文名
Message Queue
典型应用
解耦、削峰、异步。
常见产品
RabbitMQ,RocketMQ,ActiveMQ,ZeroMQ,Kafka,IBM WebSphere
中文名
消息队列
MQMQ 介绍
MQ(Message Queue)消息队列,是基础数据结构中“先进先出”的一种数据机构。指把要传输的数据(消息)放在队列中,用队列机制来实现消息传递——生产者产生消息并把消息放入队列,然后由消费者去处理。消费者可以到指定队列拉取消息,或者订阅相应的队列,由MQ服务端给其推送消息。 [1]  MQ的作用 消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。 [2]  解耦:一个业务需要多个模块共同实现,或者一条消息有多个系统需要对应处理,只需要主业务完成以后,发送一条MQ,其余模块消费MQ消息,即可实现业务,降低模块之间的耦合。异步:主业务执行结束后从属业务通过MQ,异步执行,减低业务的响应时间,提高用户体验。削峰:高并发情况下,业务异步处理,提供高峰期业务处理能力,避免系统瘫痪。MQ的缺点 [3]  1、系统可用性降低。依赖服务也多,服务越容易挂掉。需要考虑MQ瘫痪的情况2、系统复杂性提高。需要考虑消息丢失、消息重复消费、消息传递的顺序性3、业务一致性。主业务和从属业务一致性的处理
收起全文
精华内容
参与话题
问答
  • 什么是MQ?什么时候使用MQ?为什么要使用MQ

    万次阅读 多人点赞 2018-04-20 00:01:56
    只是代码的搬运工~~~~~问题1:什么是MQ?什么时候使用MQ?为什么要使用MQMQ,是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用...
    只是代码的搬运工~~~~~
    问题1:什么是MQ?什么时候使用MQ?为什么要使用MQ?
    MQ,是一种跨进程的通信机制,用于上下游传递消息。
    在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务
    使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。
    问题1:什么是MQ?什么时候使用MQ?为什么要使用MQ?
    MQ,是一种跨进程的通信机制,用于上下游传递消息。
    在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务
    使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。

    问题2:什么时候使用MQ

    【典型场景一:数据驱动的任务依赖】

     什么是任务依赖,举个栗子,互联网公司经常在凌晨进行一些数据统计任务,这些任务之间有一定的依赖关系,比如:

    1task3需要使用task2的输出作为输入

    2task2需要使用task1的输出作为输入

    这样的话,tast1, task2, task3之间就有任务依赖关系,必须task1先执行,再task2执行,载task3执行。


    对于这类需求,常见的实现方式是,使用cron人工排执行时间表

    1task10:00执行,经验执行时间为50分钟

    2task21:00执行(为task1预留10分钟buffer),经验执行时间也是50分钟

    3task32:00执行(为task2预留10分钟buffer

     

    这种方法的坏处是:

    1)如果有一个任务执行时间超过了预留buffer的时间,将会得到错误的结果,因为后置任务不清楚前置任务是否执行成功,此时要手动重跑任务,还有可能要调整排班表

    2)总任务的执行时间很长,总是要预留很多buffer,如果前置任务提前完成,后置任务不会提前开始

    3)如果一个任务被多个任务依赖,这个任务将会称为关键路径,排班表很难体现依赖关系,容易出错

    4)如果有一个任务的执行时间要调整,将会有多个任务的执行时间要调整


    无论如何,采用“cron排班表”的方法,各任务耦合,谁用过谁痛谁知道

     


    优化方案是,采用MQ解耦:

    1task1准时开始,结束后发一个“task1 done”的消息

    2task2订阅“task1 done”的消息,收到消息后第一时间启动执行,结束后发一个“task2 done”的消息

    3task3同理

     

    采用MQ优点是:

    1)不需要预留buffer,上游任务执行完,下游任务总会在第一时间被执行

    2)依赖多个任务,被多个任务依赖都很好处理,只需要订阅相关消息即可

    3)有任务执行时间变化,下游任务都不需要调整执行时间

     

    需要特别说明的是,MQ只用来传递上游任务执行完成的消息,并不用于传递真正的输入输出数据

     

    【典型场景二:上游不关心执行结果】

    上游需要关注执行结果时要用“调用”,上游不关注执行结果时,就可以使用MQ了。

     

    举个栗子58同城的很多下游需要关注“用户发布帖子”这个事件,比如招聘用户发布帖子后,招聘业务要奖励58豆,房产用户发布帖子后,房产业务要送2个置顶,二手用户发布帖子后,二手业务要修改用户统计数据。

     


    对于这类需求,常见的实现方式是,使用调用关系

    帖子发布服务执行完成之后,调用下游招聘业务、房产业务、二手业务,来完成消息的通知,但事实上,这个通知是否正常正确的执行,帖子发布服务根本不关注。

     

    这种方法的坏处是:

    1)帖子发布流程的执行时间增加

    2)下游服务当机,可能导致帖子发布服务受影响,上下游逻辑+物理依赖严重

    3)每当增加一个需要知道“帖子发布成功”信息的下游,修改代码的是帖子发布服务,这一点是最恶心的,属于架构设计中典型的依赖倒转谁用过谁痛谁知道(采用此法的请评论留言)

     


    优化方案是,采用MQ解耦:

    1)帖子发布成功后,向MQ发一个消息

    2)哪个下游关注“帖子发布成功”的消息,主动去MQ订阅

     

    采用MQ优点是:

    1)上游执行时间短

    2上下游逻辑+物理解耦,除了与MQ有物理连接,模块之间都不相互依赖

    3新增一个下游消息关注方,上游不需要修改任何代码

     

    典型场景三:上游关注执行结果,但执行时间很长】

     有时候上游需要关注执行结果,但执行结果时间很长(典型的是调用离线处理,或者跨公网调用),也经常使用回调网关+MQ来解耦。

     

    举个栗子,微信支付,跨公网调用微信的接口,执行时间会比较长,但调用方又非常关注执行结果,此时一般怎么玩呢?


    一般采用“回调网关+MQ”方案来解耦:

    1)调用方直接跨公网调用微信接口

    2)微信返回调用成功,此时并不代表返回成功

    3)微信执行完成后,回调统一网关

    4)网关将返回结果通知MQ

    5)请求方收到结果通知

     

    这里需要注意的是,不应该由回调网关来调用上游来通知结果,如果是这样的话,每次新增调用方,回调网关都需要修改代码,仍然会反向依赖,使用回调网关+MQ的方案,新增任何对微信支付的调用,都不需要修改代码啦。




    问题3:什么时候不使用MQ?
    既然MQ是互联网分层架构中的解耦利器,那所有通讯都使用MQ岂不是很好?这是一个严重的误区,调用与被调用的关系,是无法被MQ取代的。

    问题4:MQ不足?
    1系统更复杂,多了一个MQ组件
    2消息传递路径更长,延时会增加
    3)消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证
    4上游无法知道下游的执行结果,这一点是很致命的

    举个栗子用户登录场景,登录页面调用passport服务,passport服务的执行结果直接影响登录结果,此处的“登录页面”与“passport服务”就必须使用调用关系,而不能使用MQ通信。
     
    无论如何,记住这个结论调用方实时依赖执行结果的业务场景,请使用调用,而不是MQ

    展开全文
  • 消息队列MQ的使用流程

    万次阅读 多人点赞 2018-09-19 19:21:21
    在大型平台的分布式项目中,消息队列MQ具有重要的作用,经常用在边缘业务功能的处理中,比如日志管理【下面将以Bug日志保存为例】,因为像日志保存、新用户注册发送邮件等操作都不是主干业务,可以放在消息队列异步...

    人工智能,零基础入门!http://www.captainbed.net/inner

    一、简介

    在大型平台的分布式项目中,消息队列MQ具有重要的作用,经常用在边缘业务功能的处理中,比如日志管理【下面将以Bug日志保存为例】,因为像日志保存、新用户注册发送邮件等操作都不是主干业务,可以放在消息队列异步处理,这样可以减小项目的阻塞和压力。下面介绍的是比较常用的一个消息队列ActiveMQ

    二、项目的一般业务逻辑

    就以Bug日志保存为例,介绍一般的业务逻辑:【如下图代码示例】

    【1】写一个接口,

    【2】然后调用注入的Service的业务逻辑方法,

    【3】接口返回结果,流程结束。

    三、要用消息队列情况的业务逻辑

    【1】首先要有另外一个新的MQ项目服务器,用于接收消息,和处理消息,暴露接口出来即可,

    【2】在原先的项目业务上修改:请求MQ项目暴露出来的接口,把数据传过去,如果是传输的数据是对象得注意这个对象进行序列话【就是实现Serializable接口】

    【3】需要注意的是,原先的项目中的service的业务逻辑代码要copy到MQ项目中,到这里你可能就明白了MQ的实现原理:原先的项目就负责发送消息给MQ项目,然后MQ项目上有一套完全一样的业务处理代码,MQ项目在拿到消息后再慢慢处理消息【异步进行】,说通俗一点,就相当于将业务转移到另外一个项目。

    四、MQ项目消息端配置 

    【1】原先项目中的service方法要copy过来,还有对应的实体类也要copy一致,

    【2】写一个接收消息的接口:

    【3】生产消息的生产端【生产者】

    【4】消费消息的消费端 【消费者】

    【5】配置queue的名字

     这是简单的运用,用起来还是蛮简单的,但是要了解里面的原理还要多多学习源码。

    展开全文
  • 消息中间件(一)MQ详解及四大MQ比较

    万次阅读 多人点赞 2018-08-29 22:05:58
    一、消息中间件相关知识 1、概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上有很多主流的消息...

    一、消息中间件相关知识

    1、概述

    消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发RocketMQ等。

     

    2、消息中间件的组成

          2.1 Broker

    消息服务器,作为server提供消息核心服务

          2.2 Producer

    消息生产者,业务的发起方,负责生产消息传输给broker,

          2.3 Consumer

    消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理

          2.4 Topic

    主题,发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅者,实现消息的       广播

          2.5 Queue

    队列,PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收

          2.6 Message

    消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输

     

    3 消息中间件模式分类

          3.1 点对点

    PTP点对点:使用queue作为通信载体 

    说明: 
    消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息。 
    消息被消费以后,queue中不再存储,所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。

    3.2 发布/订阅

    Pub/Sub发布订阅(广播):使用topic作为通信载体 

    说明: 
    消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到topic的消息会被所有订阅者消费。

    queue实现了负载均衡,将producer生产的消息发送到消息队列中,由多个消费者消费。但一个消息只能被一个消费者接受,当没有消费者可用时,这个消息会被保存直到有一个可用的消费者。 
    topic实现了发布和订阅,当你发布一个消息,所有订阅这个topic的服务都能得到这个消息,所以从1到N个订阅者都能得到一个消息的拷贝。

     

    4 消息中间件的优势

          4.1 系统解耦

    交互系统之间没有直接的调用关系,只是通过消息传输,故系统侵入性不强,耦合度低。

          4.2 提高系统响应时间

    例如原来的一套逻辑,完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成;通过MQ架构设计,就可将紧急重要(需要立刻响应)的业务放到该调用方法中,响应要求不高的使用消息队列,放到MQ队列中,供消费者处理。

          4.3 为大数据处理架构提供服务

    通过消息作为整合,大数据的背景下,消息队列还与实时处理架构整合,为数据处理提供性能支持。

          4.4 Java消息服务——JMS

    Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。 
    JMS中的P2P和Pub/Sub消息模式:点对点(point to point, queue)与发布订阅(publish/subscribe,topic)最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

     

    5 消息中间件应用场景

           5.1 异步通信

    有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。

          5.2 解耦

    降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

          5.3 冗余

    有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。

          5.4 扩展性

    因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

          5.5 过载保护

    在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

          5.6 可恢复性

    系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

          5.7 顺序保证

    在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。

          5.8 缓冲

    在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

          5.9 数据流处理

    分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择。

     

    6 消息中间件常用协议

          6.1 AMQP协议

    AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同开发语言等条件的限制。 
    优点:可靠、通用

          6.2 MQTT协议

    MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分。该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器(比如通过Twitter让房屋联网)的通信协议。 
    优点:格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

          6.3 STOMP协议

    STOMP(Streaming Text Orientated Message Protocol)是流文本定向消息协议,是一种为MOM(Message Oriented Middleware,面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式,允许客户端与任意STOMP消息代理(Broker)进行交互。 
    优点:命令模式(非topic\queue模式)

          6.4 XMPP协议

    XMPP(可扩展消息处理现场协议,Extensible Messaging and Presence Protocol)是基于可扩展标记语言(XML)的协议,多用于即时消息(IM)以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输,这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息,即使其操作系统和浏览器不同。 
    优点:通用公开、兼容性强、可扩展、安全性高,但XML编码格式占用带宽大

          6.5 其他基于TCP/IP自定义的协议

    有些特殊框架(如:redis、kafka、zeroMq等)根据自身需要未严格遵循MQ规范,而是基于TCP\IP自行封装了一套协议,通过网络socket接口进行传输,实现了MQ的功能。

     

    7 常见消息中间件MQ介绍

          7.1 RocketMQ

    阿里系下开源的一款分布式、队列模型的消息中间件,原名Metaq,3.0版本名称改为RocketMQ,是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品(Notify、metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构,目前主要多用于订单交易系统。

    具有以下特点:

    • 能够保证严格的消息顺序
    • 提供针对消息的过滤功能
    • 提供丰富的消息拉取模式
    • 高效的订阅者水平扩展能力
    • 实时的消息订阅机制
    • 亿级消息堆积能力

    官方提供了一些不同于kafka的对比差异: 
    https://rocketmq.apache.org/docs/motivation/

          7.2 RabbitMQ

    使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP,STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了Broker架构,核心思想是生产者不会将消息直接发送给队列,消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

          7.3 ActiveMQ

    Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持,比如:in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

          7.4 Redis

    使用C语言开发的一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。

          7.5 Kafka

    Apache下的一个子项目,使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统,具有以下特性:

    • 快速持久化:通过磁盘顺序读写与零拷贝机制,可以在O(1)的系统开销下进行消息持久化;
    • 高吞吐:在一台普通的服务器上既可以达到10W/s的吞吐速率;
    • 高堆积:支持topic下消费者较长时间离线,消息堆积量大;
    • 完全的分布式系统:Broker、Producer、Consumer都原生自动支持分布式,依赖zookeeper自动实现复杂均衡;
    • 支持Hadoop数据并行加载:对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。

          7.6 ZeroMQ

    号称最快的消息队列系统,专门为高吞吐量/低延迟的场景开发,在金融界的应用中经常使用,偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,开发成本高。因此ZeroMQ具有一个独特的非中间件的模式,更像一个socket library,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列,如果down机,数据将会丢失。如:Twitter的Storm中使用ZeroMQ作为数据流的传输。

    ZeroMQ套接字是与传输层无关的:ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ,进程间(IPC) ,多播,TCP协议,在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立,断开和重连逻辑。

    特性:

    • 无锁的队列模型:对于跨线程间的交互(用户端和session)之间的数据交换通道pipe,采用无锁的队列算法CAS;在pipe的两端注册有异步事件,在读或者写消息到pipe的时,会自动触发读写事件。
    • 批量处理的算法:对于批量的消息,进行了适应性的优化,可以批量的接收和发送消息。
    • 多核下的线程绑定,无须CPU切换:区别于传统的多线程并发模式,信号量或者临界区,zeroMQ充分利用多核的优势,每个核绑定运行一个工作者线程,避免多线程之间的CPU切换开销。

     

    二、主要消息中间件的比较

     

    综合选择RabbitMq 

    展开全文
  • MQ详解及四大MQ比较

    万次阅读 2019-01-11 20:58:57
    一、消息中间件相关知识 1、概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上有很多主流的消息...

    一、消息中间件相关知识

    1、概述

    消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发RocketMQ等。

     

    2、消息中间件的组成

          2.1 Broker

    消息服务器,作为server提供消息核心服务

          2.2 Producer

    消息生产者,业务的发起方,负责生产消息传输给broker,

          2.3 Consumer

    消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理

          2.4 Topic

    主题,发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅者,实现消息的       广播

          2.5 Queue

    队列,PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收

          2.6 Message

    消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输

     

    3 消息中间件模式分类

          3.1 点对点

    PTP点对点:使用queue作为通信载体 

    说明: 
    消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息。 
    消息被消费以后,queue中不再存储,所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。

    3.2 发布/订阅

    Pub/Sub发布订阅(广播):使用topic作为通信载体 

    说明: 
    消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到topic的消息会被所有订阅者消费。

    queue实现了负载均衡,将producer生产的消息发送到消息队列中,由多个消费者消费。但一个消息只能被一个消费者接受,当没有消费者可用时,这个消息会被保存直到有一个可用的消费者。 
    topic实现了发布和订阅,当你发布一个消息,所有订阅这个topic的服务都能得到这个消息,所以从1到N个订阅者都能得到一个消息的拷贝。

     

    4 消息中间件的优势

          4.1 系统解耦

    交互系统之间没有直接的调用关系,只是通过消息传输,故系统侵入性不强,耦合度低。

          4.2 提高系统响应时间

    例如原来的一套逻辑,完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成;通过MQ架构设计,就可将紧急重要(需要立刻响应)的业务放到该调用方法中,响应要求不高的使用消息队列,放到MQ队列中,供消费者处理。

          4.3 为大数据处理架构提供服务

    通过消息作为整合,大数据的背景下,消息队列还与实时处理架构整合,为数据处理提供性能支持。

          4.4 Java消息服务——JMS

    Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。 
    JMS中的P2P和Pub/Sub消息模式:点对点(point to point, queue)与发布订阅(publish/subscribe,topic)最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

     

    5 消息中间件应用场景

           5.1 异步通信

    有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。

          5.2 解耦

    降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

          5.3 冗余

    有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。

          5.4 扩展性

    因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

          5.5 过载保护

    在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

          5.6 可恢复性

    系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

          5.7 顺序保证

    在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。

          5.8 缓冲

    在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

          5.9 数据流处理

    分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择。

     

    6 消息中间件常用协议

          6.1 AMQP协议

    AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同开发语言等条件的限制。 
    优点:可靠、通用

          6.2 MQTT协议

    MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分。该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器(比如通过Twitter让房屋联网)的通信协议。 
    优点:格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

          6.3 STOMP协议

    STOMP(Streaming Text Orientated Message Protocol)是流文本定向消息协议,是一种为MOM(Message Oriented Middleware,面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式,允许客户端与任意STOMP消息代理(Broker)进行交互。 
    优点:命令模式(非topic\queue模式)

          6.4 XMPP协议

    XMPP(可扩展消息处理现场协议,Extensible Messaging and Presence Protocol)是基于可扩展标记语言(XML)的协议,多用于即时消息(IM)以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输,这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息,即使其操作系统和浏览器不同。 
    优点:通用公开、兼容性强、可扩展、安全性高,但XML编码格式占用带宽大

          6.5 其他基于TCP/IP自定义的协议

    有些特殊框架(如:redis、kafka、zeroMq等)根据自身需要未严格遵循MQ规范,而是基于TCP\IP自行封装了一套协议,通过网络socket接口进行传输,实现了MQ的功能。

     

    7 常见消息中间件MQ介绍

          7.1 RocketMQ

    阿里系下开源的一款分布式、队列模型的消息中间件,原名Metaq,3.0版本名称改为RocketMQ,是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品(Notify、metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构,目前主要多用于订单交易系统。

    具有以下特点:

    • 能够保证严格的消息顺序
    • 提供针对消息的过滤功能
    • 提供丰富的消息拉取模式
    • 高效的订阅者水平扩展能力
    • 实时的消息订阅机制
    • 亿级消息堆积能力

    官方提供了一些不同于kafka的对比差异: 
    https://rocketmq.apache.org/docs/motivation/

          7.2 RabbitMQ

    使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP,STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了Broker架构,核心思想是生产者不会将消息直接发送给队列,消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

          7.3 ActiveMQ

    Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持,比如:in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

          7.4 Redis

    使用C语言开发的一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。

          7.5 Kafka

    Apache下的一个子项目,使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统,具有以下特性:

    • 快速持久化:通过磁盘顺序读写与零拷贝机制,可以在O(1)的系统开销下进行消息持久化;
    • 高吞吐:在一台普通的服务器上既可以达到10W/s的吞吐速率;
    • 高堆积:支持topic下消费者较长时间离线,消息堆积量大;
    • 完全的分布式系统:Broker、Producer、Consumer都原生自动支持分布式,依赖zookeeper自动实现复杂均衡;
    • 支持Hadoop数据并行加载:对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。

          7.6 ZeroMQ

    号称最快的消息队列系统,专门为高吞吐量/低延迟的场景开发,在金融界的应用中经常使用,偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,开发成本高。因此ZeroMQ具有一个独特的非中间件的模式,更像一个socket library,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列,如果down机,数据将会丢失。如:Twitter的Storm中使用ZeroMQ作为数据流的传输。

    ZeroMQ套接字是与传输层无关的:ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ,进程间(IPC) ,多播,TCP协议,在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立,断开和重连逻辑。

    特性:

    • 无锁的队列模型:对于跨线程间的交互(用户端和session)之间的数据交换通道pipe,采用无锁的队列算法CAS;在pipe的两端注册有异步事件,在读或者写消息到pipe的时,会自动触发读写事件。
    • 批量处理的算法:对于批量的消息,进行了适应性的优化,可以批量的接收和发送消息。
    • 多核下的线程绑定,无须CPU切换:区别于传统的多线程并发模式,信号量或者临界区,zeroMQ充分利用多核的优势,每个核绑定运行一个工作者线程,避免多线程之间的CPU切换开销。

     

    二、主要消息中间件的比较

     

    综合选择RabbitMq 

    from https://blog.csdn.net/wqc19920906/article/details/82193316

    展开全文
  • ActiveMQ Kafka RabbtiMQ
  • 几种常见的MQ总结对比

    千次阅读 2020-06-27 12:12:08
    不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。 没有对自己的架构问过为什么的人,一定是平时...
  • MQ

    2020-04-04 16:10:16
    MQActiveMQ点对点:Queue,不可重复消费发布/订阅:Topic,可以重复消费SpringBoot整合ActiveMQ ActiveMQ ActiveMQ是一种开源的基于JMS(Java Message Servie)规范的一种消息中间件的实现,ActiveMQ的设计目标是...
  • MQ学习笔记整理

    千次阅读 2018-11-12 12:24:40
    MQ学习笔记 一、为什么要使用MQ? 其实这里要讲的就是使用MQ的好处,MQ的的使用场景有很多,但是比较核心的有3个:解耦、异步、削峰 1. 解耦 例如:A系统要发送数据到B、C、D三个系统,通过接口调用发送。假如...
  • RabbitMQ教程-万字长文详解RabbitMQ

    万次阅读 多人点赞 2018-08-05 23:14:56
    RabbitMQ教程。RabbitMQ详解。消息队列(MQ),本质是个队列,队列中存放的内容是message。MQ用于不同进程Process/线程Thread之间通信。本文介绍RabbitMQ的使用。RabbitMQ实战教程。
  • mq的基本介绍和基本用法

    万次阅读 多人点赞 2018-08-04 11:54:41
    1.什么是MQ,有什么用? MQ 是message queue ,消息队列,也叫消息中间件,遵守JMS(java message service)规范的一种软件。(同时还有另一个叫AMQP的应用层协议,语言无关性不受产品 语言等限制,rabbitMQ支持这个 )...
  • 【消息队列MQ】各类MQ比较

    万次阅读 多人点赞 2012-09-11 21:22:24
    目前业界有很多MQ产品,我们作如下对比: RabbitMQ 是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了...
  • 消息中间件MQRabbitMQ面试题(2020最新版)

    万次阅读 多人点赞 2020-03-01 11:11:21
    文章目录为什么使用MQMQ的优点消息队列有什么优缺点?RabbitMQ有什么优缺点?你们公司生产环境用的是什么消息中间件?Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?MQ 有哪些常见问题?如何解决这些问题?...
  • 最近soa项目要和官网系统对接,实现mq信息监听,保存等一些列操作。项目用的是Maven+SSM框架。然后学习和开发用了两天时间,算是搞定,趁加班时间做个总结。
  • Spring Boot整合RabbitMQ详细教程

    万次阅读 多人点赞 2018-05-14 17:26:11
    1.首先我们简单了解一下消息中间件的应用场景 异步处理 场景说明:用户注册后,需要发注册邮件...2.并行的方式 ... 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西. ...
  • SpringBoot整合RabbitMQ之 典型应用场景实战一

    万次阅读 多人点赞 2018-10-09 15:08:04
    RabbitMQ 作为目前应用相当广泛的消息中间件,在企业级应用、微服务应用中充当着重要的角色。特别是在一些典型的应用场景以及业务模块中具有重要的作用,比如业务服务模块解耦、异步通信、高并发限流、超时业务、...
  • RabbitMQ简介,各种MQ选型对比

    千次阅读 2018-04-26 09:58:40
    队列是什么,MQ 我们可以理解为消息队列,队列我们可以理解为管道。以管道的方式做消息传递。场景: 1.其实我们在双11的时候,当我们凌晨大量的秒杀和抢购商品,然后去结算的时候,就会发现,界面会提醒我们,让...
  • RabbitMQ之消息持久化

    万次阅读 热门讨论 2017-03-08 16:53:06
    消息的可靠性是RabbitMQ的一大特色,那么RabbitMQ是如何保证消息可靠性的呢——消息持久化。 为了保证RabbitMQ在退出或者crash等异常情况下数据没有丢失,需要将queue,exchange和Message都持久化。 queue的...
  • 前言: MQ 是什么?队列是什么,MQ 我们可以理解为消息队列,队列我们可以理解为管道。以管道的方式做消息传递。场景: 1.其实我们在双11的时候,当我们凌晨大量的秒杀和抢购商品,然后去结算的时候,就会发现,...
  • MQ选型对比RabbitMQ RocketMQ ActiveMQ

    万次阅读 2018-01-08 17:20:19
    几种MQ产品说明:  ZeroMQ : 扩展性好,开发比较灵活,采用C语言实现,实际上他只是一个socket库的重新封装,如果我们做为消息队列使用,需要开发大量的代码  RabbitMQ :结合erlang语言本身的并发优势,...
  • MQ对比之RabbitMQ & Redis

    2020-01-29 23:44:55
    消息队列选择:RabbitMQ & Redis RabbitMQ RabbitMQ是一个由erlang开发的AMQP(Advanced Message Queue )的开源实现的产品,RabbitMQ是一个消息代理,从“生产者”接收消息并传递消息至“消费者”,期间可根据...
  • MQ全称为Message Queue(消息队列),是在消息的传输过程中保存消息的容器,多用于分布式系统之间进行通信。分布式系统通信有两种方式,一种是直接远程调用另一种是借助中间件来完成间接通信。通信的发送方为生产者,...
  • MQRabbitMQ作用特点

    万次阅读 2018-09-09 10:24:10
    MQ的作用:  解耦:在项目启动之初是很难预测未来会遇到什么困难的,消息中间件在处理过程中插入了一个隐含的,基于数据的接口层,两边都实现这个接口,这样就允许独立的修改或者扩展两边的处理过程,只要两边遵守...
  • 文章目录通过RabbitMQ 死信队列实现延迟MQ消息,消息延迟,MQ延迟队列1、延迟消息原理2、如何在Springboot 下创建延迟消息队列3、可能会遇到的问题:项目启动报错4、可能会遇到的问题:在设置了统一的过期时间后,又...
  • MQ - RabbitMQ - 架构及工作原理

    万次阅读 2018-07-05 16:16:44
    1. 系统架构几个概念说明: Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线,保证数据能按照指定的方式进行传输, Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。...
  • 首先,MQ其实就是消息队列,队列我们可以理解为管道,以管道的放手做消息传递。 1. RabbitMQ,ActiveMq,ZeroMq比较 TPS比较: ZeroMq 最好,RabbitMq 次之, ActiveMq 最差。 持久化消息: ZeroMQ不支持。ActiveMQ和...
  • MQ选型对比RabbitMQ RocketMQ ActiveMQ Kafka

    万次阅读 热门讨论 2016-05-06 13:44:04
    MQ选型对比文档 综合选择RabbitMq
  • RabbitMq、ActiveMq、Kafka和Redis做Mq对比

    千次阅读 2018-04-08 11:00:38
    一、RabbitMq RabbitMQ是一个Advanced Message Queuing Protocol(AMQP)的开源实现,由以高性能、可伸缩性出名的Erlang写成。RabbitMQ Server适用的OS有:Windows、Linux/Unix和Mac OS X,RabbitMQ官方的...
  • RabbitMQ消息队列+spring监听mq服务器多个ip,接收消费mq消息(三) https://blog.csdn.net/zhanglf02/article/details/77584012 背景:上个月写过一个客户端监听mq。用的是配置方式,这个配置用了...
  • rabbitmq常见面试题

    万次阅读 多人点赞 2019-04-10 15:06:02
    1、使用RabbitMQ有什么好处? 1.解耦,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦! 2.异步,将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应...
  • MQ消息堆积终极解决方案【RabbitMQ

    千次阅读 2020-06-12 18:34:11
    如果架构中有用到mq,那就不可避免会遇到消息堆积的问题,因为我们没办法保证自己生产和消费永远都是正确的。像我们系统就遇到过很多次消息堆积情况,最严重的一次直接导致mq内存溢出,服务宕机,导致所有的mq消费...

空空如也

1 2 3 4 5 ... 20
收藏数 226,325
精华内容 90,530
关键字:

mq