精华内容
下载资源
问答
  • 2019-07-04 01:11:40

    协议很常见,只要是通信,就会用到协议,就像我们说话的语言一样,不同的语言连通着不同的人群。
    所以说,消息队列也是一样,想要互相通信,就要使用同一种协议。
    每个协议下的消息队列,都有着不同的角色定义。
    简单说下常见的消息队列协议:

    1.AMQP(Advance Message Queuing Protocol)

    Message(消息):消息服务器处理消息的原子单元,包括一个内容头,一组属性和一个内容体。
    消息有优先级,高优先级的消息在等待同一消息队列时会比低优先级的消息先发送,而且当消息必须被丢弃时,低优先级的消息优先被丢弃。
    使用AMQP协议,消息服务器不能修改内容体和内容头,但可以在内容头上添加额外信息。
    PubLisher(消息生产者):发送消息
    Consumer(消息消费者):消费消息
    Broker(消息代理):消息队列服务器,负责接收客户端连接,路由消息。
    Queue(消息队列):Broker中的一个角色,一个Broker中可以有多个Queue,负责保存消息直到发送给不同的消费者。算是消息的容器。一个消息可以被投入一个或多个队列中,每个队列的消息都会等待消费者连接到这个队列并被取走。
    Exchange(交换路由):Broker中的一个角色,负责接收生产者发送的消息,并路由给服务器中的队列。可以被理解成一个规则表,指明消息该被投到哪个队列中。
    Channel(信道):信道是一条独立的双向数据流通道。为了解决操作系统无法承受每秒建立特别多的TCP连接。

    生产者发送消息时,必须指定消息要被路由到哪些个消息队列中。
    当消息到消息队列中,消息队列会尝试将消息传给消费者,如果失败,消息队列会存储消息并等待消费者。
    如果没有消费者,消息队列将选择性的将消息返回给生产者。
    如果消息别消费掉,消息队列会删除消息,删除的过程或者是及时的,或者是等到消费者消费结果后才删除的。

    AMQP是二进制协议。

    2.MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)

    由IBM开发,现在被广泛用于物联网公司。因为他的特点就是轻量,简单,开放和易于实现。所以他常用于很多计算能力有限、带宽低、网络不可靠的远程通信应用场景。
    Publisher(发布者):消息发布客户端
    Subscriber(订阅者):消息订阅客户端
    Broker(消息代理):消息服务器端
    Application Message(应用消息):指通过网络传输的应用数据,一般包括主题和负载。
    Topic(主题):应用消息的类型,一般消息发布者会确定消息的主题,订阅者根据自己实际情况选择不同的主题进行消息订阅消费。
    Payload(负载):消息订阅者具体接收的内容。

    MQTT协议是通过交换预定义的MQTT控制报文来通信的。
    控制报文内容由三部分组成:固定报头,可变报头和消息体。
    固定报头通过标识不同位的值来确定报文类型,包括发布订阅的一些完成状态等。
    可变报头的内容根据控制报文类型不同而不同,常作为包的标识符。
    消息体也是根据不同的消息类型有着不同的内容。

    MQTT协议中,客户端和服务端是通过请求应答模式通信的。客户端发送一条控制报文数据给服务器,服务器再发送一条控制报文数据给客户端。

    MQTT在发布消息时,有三种Qos等级:至多一次(0级),至少一次(1级),只有一次(2级)。
    至多一次等级最低,客户端只需要将消息发出去即可,这种等级很low,用于消息不重要但特别多,为了减轻通信压力,就不顾质量,只看数量了。
    至少一次等级中等,客户端要保证发出去的消息至少一次被服务端接收到,所以要收到服务端的回应,否则一直发,这种等级一般用于服务端有幂等处理,所以不怕重复消费,还要保证消息不会丢失。
    只有一次等级最高,客户端先发消息过去,然后本地记录一个我已发送,但不确定你是否收到的状态,然后服务端接收到消息后,回给客户端一个我已接收的报文,同时服务端记录一个我不确定你知不知道我已接收的状态,然后客户端收到这个已接收的消息后,就确定服务端收到这个消息了,于是把自己本地记录的已发送未确定的状态删除,同时再给客户端发送一个我已经知道你收到的报文,服务端收到这个报文,也会把自己之前记录的状态删掉,整个一条报文只有一次的通信才算完成,这种等级就比较严格了,但质量上去了,相对低等级的,数量就会相对小些,但可靠就是王道,不多不少才是最好的。
    只有一次的发送和确定,其实思想和三次握手差不多,都是两端互相确认的过程,所以会一来一回的。如果传输过程中出现丢包,都会由发送者重发上一条消息。

    3.STOMP(Streaming Text Orientated Messaging Protocal,流文本定向消息协议)

    STOMP是一个相对简单的文本消息传输协议,主要特点就是简单易懂,没有特别多的套路。
    客户端:既可以是生产者,也可以是消费者
    服务端:消息中心

    4.XMPP(可扩展通信与表达协议)

    基于XML的流式即时通信协议。
    由于用的XML,所以通用性更强。
    客户端:生产者,消费者
    服务端:消息中心
    XMPP的理念是尽可能的简化客户端,复杂的都放在服务端。

    5.JMS(Java Message Service,java消息服务应用程序接口)

    java消息服务应用接口,是一套java API接口。
    JMS是规范,是对AMQP,MQTT,STOMP,XMPP等协议更高一层的抽象。

    更多相关内容
  • amqp高级消息队列协议v1.0
  • AMQP高级消息队列协议

    千次阅读 2018-08-22 12:42:19
    AMQP,即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/...

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

    AMQP模型(AMQP Model):一个由关键实体和语义表示的逻辑框架,遵从AMQP规范的服务器必须提供这些实体和语义。为了实现本规范中定义的语义,客户端可以发送命令来控制AMQP服务器。

    连接(Connection):一个网络连接,比如TCP/IP套接字连接。

    会话(Session):端点之间的命名对话。在一个会话上下文中,保证“恰好传递一次”。

    信道(Channel):多路复用连接中的一条独立的双向数据流通道。为会话提供物理传输介质。

    客户端(Client):AMQP连接或者会话的发起者。AMQP是非对称的,客户端生产和消费消息,服务器存储和路由这些消息。

    服务器(Server):接受客户端连接,实现AMQP消息队列和路由功能的进程。也称为“消息代理”。

    端点(Peer):AMQP对话的任意一方。一个AMQP连接包括两个端点(一个是客户端,一个是服务器)。

    搭档(Partner):当描述两个端点之间的交互过程时,使用术语“搭档”来表示“另一个”端点的简记法。比如我们定义端点A和端点B,当它们进行通信时,端点B是端点A的搭档,端点A是端点B的搭档。

    片段集(Assembly):段的有序集合,形成一个逻辑工作单元。

    段(Segment):帧的有序集合,形成片段集中一个完整子单元。

    帧(Frame):AMQP传输的一个原子单元。一个帧是一个段中的任意分片。

    控制(Control):单向指令,AMQP规范假设这些指令的传输是不可靠的。

    命令(Command):需要确认的指令,AMQP规范规定这些指令的传输是可靠的。

    异常(Exception):在执行一个或者多个命令时可能发生的错误状态。

    类(Class):一批用来描述某种特定功能的AMQP命令或者控制。

    消息头(Header):描述消息数据属性的一种特殊段。

    消息体(Body):包含应用程序数据的一种特殊段。消息体段对于服务器来说完全透明——服务器不能查看或者修改消息体。

    消息内容(Content):包含在消息体段中的的消息数据。

    交换器(Exchange):服务器中的实体,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。

    交换器类型(Exchange Type):基于不同路由语义的交换器类。

    消息队列(Message Queue):一个命名实体,用来保存消息直到发送给消费者。

    绑定器(Binding):消息队列和交换器之间的关联。

    绑定器关键字(Binding Key):绑定的名称。一些交换器类型可能使用这个名称作为定义绑定器路由行为的模式。

    路由关键字(Routing Key):一个消息头,交换器可以用这个消息头决定如何路由某条消息。

    持久存储(Durable):一种服务器资源,当服务器重启时,保存的消息数据不会丢失。

    临时存储(Transient):一种服务器资源,当服务器重启时,保存的消息数据会丢失。

    持久化(Persistent):服务器将消息保存在可靠磁盘存储中,当服务器重启时,消息不会丢失。

    非持久化(Non-Persistent):服务器将消息保存在内存中,当服务器重启时,消息可能丢失。

    消费者(Consumer):一个从消息队列中请求消息的客户端应用程序。

    生产者(Producer):一个向交换器发布消息的客户端应用程序。

    虚拟主机(Virtual Host):一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。客户端应用程序在登录到服务器之后,可以选择一个虚拟主机。

    下面这些术语在AMQP规范的上下文中没有特别的意义:

    主题:通常指发布消息;AMQP规范用一种或多种交换器来实现主题。

    服务:通常等同于服务器。AMQP规范使用“服务器”这个术语来兼容IETF的标准术语,并且明确了协议中每个部分的角色(两方也可能是AMQP服务)。

    消息代理:等同于服务器。AMQP规范使用术语“客户端”和“服务器”来兼容IETF的标准术语。

    摩根大通和iMatrix开始着手Advanced Message Queuing Protocol (AMQP)开放标准的开发。2006年,AMQP规范发布。2007年,Rabbit技术公司基于AMQP标准开发的RabbitMQ 1.0 发布。

    目前RabbitMQ的最新版本为3.5.7,基于AMQP 0-9-1。 

    RabbitMQ采用Erlang语言开发。Erlang语言由Ericson设计,专门为开发concurrent和distribution系统的一种语言,在电信领域使用广泛。OTP(Open Telecom Platform)作为Erlang语言的一部分,包含了很多基于Erlang开发的中间件/库/工具,如mnesia/SASL,极大方便了Erlang应用的开发。OTP就类似于Python语言中众多的module,用户借助这些module可以很方便的开发应用。

    • Broker: 接收和分发消息的应用,RabbitMQ Server就是Message Broker。
    • Virtual host: 出于多租户和安全因素设计的,把AMQP的基本组件划分到一个虚拟的分组中,类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时,可以划分出多个vhost,每个用户在自己的vhost创建exchange/queue等。
    • Connection: publisher/consumer和broker之间的TCP连接。断开连接的操作只会在client端进行,Broker不会断开连接,除非出现网络故障或broker服务出现问题。
    • Channel: 如果每一次访问RabbitMQ都建立一个Connection,在消息量大的时候建立TCP Connection的开销将是巨大的,效率也较低。Channel是在connection内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的channel进行通讯,AMQP method包含了channel id帮助客户端和message broker识别channel,所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
    • Exchange: message到达broker的第一站,根据分发规则,匹配查询表中的routing key,分发消息到queue中去。常用的类型有:direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
    • Queue: 消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。
    • Binding: exchange和queue之间的虚拟连接,binding中可以包含routing key。Binding信息被保存到exchange中的查询表中,用于message的分发依据。

    生产者发送消息到broker server(RabbitMQ)。在Broker内部,用户创建Exchange/Queue,通过Binding规则将两者联系在一起。Exchange分发消息,根据类型/binding的不同分发策略有区别。消息最后来到Queue中,等待消费者取走。

    Exchange有多种类型,最常用的是Direct/Fanout/Topic三种类型。

    Direct 

    Message中的“routing key”如果和Binding中的“binding key”一致, Direct exchange则将message发到对应的queue中。

    Fanout 

    每个发到Fanout类型Exchange的message都会分到所有绑定的queue上去。

    Topic 

    根据routing key,及通配规则,Topic exchange将分发到目标queue中。

    Routing key中可以包含两种通配符,类似于正则表达式:

    “#”通配任何零个或多个word
    “*”通配任何单个word

    http://tryrabbitmq.com/ 它提供在线RabbitMQ 模拟器,可以帮助理解Exchange/queue/binding概念。 

    展开全文
  • AMQPClient.jl:Julia AMQP(高级消息队列协议)RabbitMQ客户端
  • AMQP (Advanced Message Queuing Portocol) ...# 一套被称作高级消息队列模型 AMQ Model 的消息能力定义: 该模型涵盖了 Broker 中用于路由和存储消息的组件,以及把这些组件连在一起的规则 # 一个网络层协

    AMQP (Advanced Message Queuing Portocol)

    
    AMQP
    # 是应用层协议的开放标准,为面向消息的中间件设计,基于此协议的客户端与消息中间件可直接传递消息而不受产品、开发语言等的限制
    # AMQP 覆盖的内容包含网络协议及服务端,其设计目标是让服务端可通过协议进行"编程"(Tips: 属于二进制协议)
    # 一套被称作高级消息队列模型 AMQ Model 的消息能力定义: 该模型涵盖了 Broker 中用于路由和存储消息的组件,以及把这些组件连在一起的规则
    # 一个网络层协议 AMQP,让客户端程序与实现了 AMQ Model 的服务端进行通信 ...
    # RabbitMQ 是采用 Erlang 编写的实现了 AMQP 协议的开源消息代理软件
    # https://www.rabbitmq.com/tutorials/amqp-concepts.html
    # https://zhuanlan.zhihu.com/p/147675691
    
    # ----------------------------------------------------------------- Example
    # 
    #                    /-------------------------\  
    #     *producer ==> |*Exchange => *Message Queue| ==> *Consumer
    #                    \-------------------------/  
    #                             AMQP 实体  
    # 
    # ----------------------------------------------------------------- RabbitMQ
    
    Message
    # 即传输的消息内容,它包含两部分:
    #   1.有效载荷 Payload 即传输的数据,数据类型可以是纯文本或JSON
    #   2.标签 Lable 包含交换机名字和可选的主题 Topic 标记等 ...
    # AMQP 模型中的 Message 对象是有属性的,它与 HTTP 的 X-Headers 类似,其属性在消息被生产者端发布时进行定义 ...
    # 有些属性很常见,以至于 AMQP 0-9-1 进行了明确定义:
    #   Content type(内容类型)
    #   Content encoding(内容编码)
    #   Routing key(路由键)
    #   Delivery mode (persistent or not) 投递模式(持久化或非持久化)
    #   Message priority(消息优先级)
    #   Message publishing timestamp(消息发布的时间戳)
    #   Expiration period(消息有效期)
    #   Publisher application id(发布的应用ID)
    
    Queue  
    # 属于服务器的组件,存储即将被消费的消息,该队列可在集群节点间进行镜像,以确保硬件故障时仍保证消息安全
    # Exchange 不存储消息,消息只能存储在 Queue 中,消费者通过订阅 Queue 来获取消息...
    # Tips: 当多个消费者订阅相同的 Queue 时消息会被平均的分摊给多个消费者进行处理
    # 小兔子支持多种消息队列协议,队列跟交换机共享某些属性,但队列也有些另外的属性: (declare: 队列在声明后才可使用)
    #   1.Name          队列名称
    #   2.Durable       消息代理重启后,队列依旧存在 (持久化) 
    #   3.Exclusive     只被一个连接 connection 使用,且当连接关闭后队列即被删除(独占)...
    #   4.Auto-delete   当最后一个消费者退订后即被删除
    #   5.Arguments     一些消息代理用它来完成类似于 TTL 的某些额外功能 ...
    # Tips: 上述队列属性是在生产者端进行设置的 ...
    
    Broker
    # 接收和分发消息的应用/代理,Rabbit Server 即 Message Broker 
    # 消息代理接收生产者的消息并将其以某种方式路由 (按指定规则转发) 到对应的 consumer
    # 因为 AMQP 是网络协议,所以消息代理、生产者、消费者可以分布在不同的机器上 ...
    # 逻辑: *Producer(Connection(*Channel)) <=> RabbitMQ(*Broker(*Exchange(*Queue))) <=> Connection(*Channel)*Consumer
    
    Producer
    # 发布消息到 *Broker 中的 Exchange 的应用,发布消息时可以给消息指定各种属性 "Message Metadata"
    # 有些属性有可能会被 Broker 使用、有些属性则完全透明,只能被接收消息的应用使用
    
    Consumer
    # 从队列中消费消息的应用,AMQP 支持 Push、Pull 的方式处理消息
    # 每个消费者/订阅者都有个叫做消费者标签的标识符,它可以被用来退订消息,该标签实际上是个字符串
    
    Exchange 交换机/器
    # 生产者消息由交换机接收,然后再从交换机分发到不同的队列,在分发过程中不同类型的交换器有着不同的分发逻辑
    # 交换机是用来发送消息的 AMQP 实体,消息经交换机路由到队列,RabbitMQ 提供了多种内置的典型的交换机类型
    # 当有较复杂的路由需求时,可将这些交换机组合使用,也可以实现自己的交换机类型并作为插件使用 ...
    # 发布者生产的消息中包含了交换机类型,消息中声明的交换机类型不同,路由规则也就不同,因此会采取不同的规则将消息投入队列
    # 当消息进入交换机时将根据消息携带的 routing key (路由键) 与队列进行绑定,它是路由到具体队列的匹配规则...
    # 交换机有四种类型:
    #   1.Direct         处理路由键,需先将队列绑定到交换机,要求该消息与特定的路由键能完全匹配(默认)
    #   2.Topic          将路由键与某模式匹配,此时队列需绑定要一个模式上,符号 # 可匹配一或多个词
    #   3.Fanout         不处理路由键,而是直接将队列绑定到交换机,交换机收到的消息会被转发到与其绑定的所有队列 (发布订阅)
    #   4.Header         不处理路由键,而是根据消息内容中的 headers 属性进行匹配,该属性是个键值对,可以是Hashtable,值可以是任何类型
    # 可以这样理解:
    #   1、routing key   是由生产者发送消息时携带的,是与消息关联的属性
    #   2、binding key   是将队列与交换机进行关联的,由消费者定义
    #   3、exchange      相当于比较这两者的组件,是某种算法逻辑 ...
    # --------------------------------------------------------------------
    # 交换机有两个状态: 持久(durable)、暂存(transient),Tips: 并非所有场景都需要持久化的交换机
    # 持久化的交换机会在消息代理重启后依旧存在,而暂存的交换机不会(它们需要在代理再次上线后重新被声明)
    # 从消息分发的性能上来比较: Fanout > Direct > Topic > Headers
    
    Routing Key
    # 生产者将消息发送给 Exchange 时会指定 routing key 参数(通过其确定该消息的路由规则)
    # 这个 routing key 需要与对应的交换器类型及 binding key 联合使用才能最终生效 ...
    # 在 Exchange Type 与 binding key 固定的情况下(在正常使用时这些内容都是固定配好的)
    # Routing key 格式由以 . 分隔的若干有意义的单词组成,并且总长度限制为 255 bytes
    
    Binding
    # 即消息队列和交换器直接的关联
    # binding key 是队列和交换机之间的绑定键,而 routing key 是生产者发给交换机的消息属性
    # 当 routing key 和 binding key 能对应上的时候就发到相应的队列中
    
    Virtual Host
    # 为多租户提供完全隔离的逻辑环境,从而为应用安全保密地处理数据,类似 C++ 的命名空间、物理机中的VM ...
    # 虚拟机是共享相同的身份认证并且加密环境独立的服务器域,客户端应用在登录到服务器之后可选择某个虚拟主机
    # 它能将同一 RabbitMQ 中的若干客户区分,避免队列和交换器等命名的冲突(每个租户表示为 vhost)
    # 其本质是个独立的逻辑 RabbitMQ 服务器,内部是用户、用户组、队列、交换器及绑定关系等的抽象集合,并拥有独立权限 ...
    
    Connection
    # 基于TCP套接字的网络连接
    # Producer 和 Consumer 均基于TCP连接到 Broker,并假设长期连接(每个协议操作不打开新连接)以提高效率
    # 程序的起始处就是建立这个连接,一个客户端库连接使用一个TCP连接...
    
    Channel
    # 是在TCP连接的基础上实现的多路复用的、独立的双向数据流通道,是建立在 TCP(Connection)基础上的虚连接
    # RabbitMQ 在单条TCP内建立成百上千个信道来达到多线程处理的目的,这个TCP被多个线程共享,每个线程对应着一个信道
    # 信道是生产者、消费者与 RabbitMQ 进行通信的渠道: 生产者发布到交换器或消费者订阅某个队列都是通过信道来通信的...
    
    

    RabbitMQ

    
    # RabbitMQ 提供许多插件进行扩展,也可以编写自己的插件
    # RabbitMQ 提供了身份认证(TLS/SSL、SASL)和权限控制(读、写操作)等安全机制
    # 它是典型的点对点模式,而Kafka是典型的发布订阅模式,但 RabbitMQ 也可以通过特定的交换器类型实现发布订阅,从而达到广播消费
    # 对 MQTT 协议的支持使其在物联网中获得一席之地,还有的消息中间件是基于其自身的私有协议运行的,典型的如 Kafka
    # 流量削峰是消息中间件非常重要的功能,这得益于其对消息的堆积能力 ...
    # 生产者可以配置成在启动时创建所有必要的基础设施 (交换器、队列、绑定)、或者也可以由消费者在启动时创建一切
    # 另一个选择是两者均不创建任何基础设施,而是通过用户界面管理插件 Management Plugin 或 Management CLI 进行设置
    
    # --------------------------------------------------
    
    Producer & Consumer
    # Producer 与 Exchange 保持连接,Producer 和 Consumer 在登录时需指定 Virtual Host
    # Producer 在投递消息时携带 Exchange 进行绑定需要的 routing key,并指定 message 投递的具体交换机名字
    # 这意味着生产者不直接与 Queue 关联,而是只与交换机进行交互
    # 相关投递细节还有: 消息是否持久化,消息投递的确认机制,消息投递的事务操作等
    # Consumer 通常会创建具体的 queue 和 exchange 然后将其 binding,根据不同的业务消费不同的消息
    # Consumer 具体其他细节还有消息应答,Qos操作、Cancel、事务操作等 ...
    
    发布确认
    # 生产者将信道设为 confirm 模式后,所有在该信道上发布的消息都将会被指派唯一的ID (从1开始)
    # 当消息被投递到所有匹配的队列之后 Broker 会发送确认给生产者 (含消息ID),使生产者知道消息已经正确到达目的队列
    # 如果队列和消息是持久化的,则确认消息将在将消息写入磁盘之后发出
    # Broker 返回的确认消息中 delivery-tag 域包含了确认消息的序列号,此外也可设置 basic.ack 的 multiple 域表示到此序号之前的所有消息都已被处理
    # confirm 模式是异步的,当发出消息后,生产者可以在等信道返回确认的同时继续发送下一条消息
    # 当消息最终得到确认之后,生产者便可以通过回调方法来处理该确认消息
    # 如果 Broker 因为内部错误导致消息丢失,就会发送 nack 消息,生产者同样可以在回调方法中处理该消息
    
    消息应答
    # 若消费者因未正常发送应答,Broker 将认为该消息未处理完全,再交给其他消费者处理(默认:autoAsk=true)
    # 分为自动应答 (autoAck=true)、手动应答 (autoAck=false) 两种模式,仅当收到消费者应答后才会将该消息从内存中删除
    # 自动应答: 不在乎消费者对消息处理是否成功,都会告诉队列删除消息,若处理消息失败,实现自动补偿(队列投递过去,重新处理)
    # 手动应答: 消费者处理完业务逻辑后手动返回 ACK,队列进而删除消息(不会丢消息)
    # Tips: 不同于 ActiveMQ,在 RabbitMQ 里的消息没有过期的概念 
    
    不公平分发 & 预取值 prefetch
    # RabbitMQ 默认采用轮训方式分发消息,但不同消费者处理消息的速度不同 ...
    # 设为不公平分发模式后,若此任务A还未处理完或A还未应答,则暂时不再分发给A,然后 rabbitmq 会把任务分配给没有那么忙的其他空闲消费者
    # 若所有消费者都未完成手中任务,而队列还在不停添加新任务,可能会遇到队列撑满的情况,此时只能添加新的 worker 或改变其他存储任务的策略
    # 预取值: 可以让 RabbitMQ 根须消费端的负载状态一次投递多个消息到消费端, 实现消息的预取 (prefetch)
    
    持久化: Message durability
    # 为保证 Broker 在退出或 crash 等异常情况下数据不丢失,需要将 queue、exchange、Message 都持久化,默认是非持久化的
    # 设置队列的持久化: durable=true,此时队列被持久化,但队列里的消息是否为持久化还要看具体消息的持久化设置
    # 设置消息的持久化: channel.basicPublish(..., ..., MessageProperties.PERSISTENT_TEXT_PLAIN,...);
    # 设置交换机持久化: channel.exchangeDeclare(exchangeName, "direct|topic|header|fanout", durable=true)
    # Tips: 设置了队列和消息的持久化之后,当 Broker 重启之后消息依旧存在 ...
    # 若不设置交换机的持久化,对消息的可靠性没什么影响,但是当 Broker 重启后交换机会不存在,此时 Producer 将不能正常发送消息 ...
    
    死信队列
    # 死信交换器和一般的 Exchange 没有区别,它能在任何队列上被指定,实际上就是设置某个队列的属性 ...
    # 当某队列中有死信时 RabbitMQ 会自动将这个死信消息重新发布到设置的 Exchange 上,进而被路由到另一个队列
    # 生产环境中需要监听此队列中存放的死信消息做相应的处理,而具体的处理逻辑和业务相关 ...
    # 消息在某些情况下将变成死信:
    # 1.消息被拒绝 (basic.reject/basic.nack),并且 requeue=false 
    # 2.消息TTL过期
    # 3.队列达到最大长度
    
    延时队列 & TTL
    # 普通队列中的元素总是希望被早点处理,而延时队列中的元素则是希望在指定时间得到取出和处理
    # 所以延时队列中的元素是带时间属性的,通常来说是需要被处理的消息或者任务
    # TTL 是消息或队列的属性,表明一条消息或该队列中所有消息的最大存活时间,单位毫秒(若同时配置队列和消息的 TTL 则较小的值将被使用)
    # 若消息设置了 TTL 或进入了设置 TTL 的队列,则该消息若在相关时间内未被消费就会成为 "死信" (延时队列依赖于死信队列)
    # -------------------------------------------------- 创建队列时设置 TTL
    # Map<String, Object> args = new HashMap<String, Object>();
    # args.put("x-message-ttl", 6000);
    # channel.queueDeclare(queueName, durable, exclusive, autoDelete, args);
    # -------------------------------------------------- 对每条消息设置 TTL
    # AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
    # builder.expiration("6000");
    # AMQP.BasicProperties properties = builder.build();
    # channel.basicPublish(exchangeName, routingKey, mandatory, properties, "msg body".getBytes());
    # --------------------------------------------------
    # 延时队列的使用场景: (特点为: 需在某事件发生之后或之前的指定时间点完成某一项任务)
    #   1.订单在十分钟内未支付则自动取消
    #   2.新创建的店铺,如果在十天内没有上传过商品,则自动发送消息提醒
    #   3.账单在一周内未支付,则自动结算
    #   4.用户注册成功后,如果三天内没登陆则进行短信提醒
    #   5.用户发起退款,如果三天内没有得到处理则通知运营人员
    #   6.预定会议后,需要在预定的时间点前十分钟通知各个与会人员参加会议
    
    镜像队列
    # https://www.bilibili.com/video/BV1cb4y1o7zz?p=85
    # 因为集群由若干 Broker 节点组成,所以从整体可用性上来讲,对于单点失效是有弹性的
    # 集群环境下尽管 Exchange 和 Binding 能在单点失效时可用,但 Queue 不行,这是因为 queue 及其内容默认仅存储在单节点中
    # 因此当某节点失效时其对应的 Queue 会不可用 ...
    # 通过将 queue 镜像到其他节点,当集群中某节点失效时 queue 能自动切换到镜像的节点来保证可用性
    # 通常针对每个镜像队列都包含一个 Master (Leader Replica) 及若干 Slave (Mirrors Replicas),分别对应于不同节点 ...
    # 由 Master 将命令执行结果广播给所有 Slave,故看似从镜像队列中的消费操作实际上是在 Master 中执行的
    # 发布到队列的消息被复制到所有镜像。无论消费者连接到哪个节点,消费者都连接到领导者,镜像会丢弃已在领导者处确认的消息
    # 镜像队列不能作为负载均衡使用,因为每个操作在所有节点都要做一遍 ...
    # 一旦完成了选中的 Slave 被提升为 Master 的动作,发到镜像队列的消息将不会再丢失
    # 镜像队列同时支持发布确认和事务两种机制: (镜像队列将在未来的版本中移除,建议使用仲裁队列实现高可用)
    #   1.事务机制: 只有当前事务在所有的镜像 queue 中执行后,客户端才会收到 Tx.CommitOk 消息
    #   2.发布确认: 向生产者进行消息确认的前提是该消息被全部镜像所接受了
    
    仲裁队列 Quorum Queues
    # 仲裁队列从 3.8.0 可用,是镜像队列的替代方案: https://www.rabbitmq.com/quorum-queues.html
    # 仲裁队列用 Raft 算法实现了持久的、复制的 FIFO 队列,更加专注于数据安全,是镜像队列的后继者 ...
    # 与经典的镜像队列相比,仲裁队列在行为和一些限制方面有重要的差异
    # 常规队列可能是非持久的,仲裁队列始终是持久的,仲裁队列不能用作临时队列
    # Quorum 队列目前不支持 Message TTL,但支持 Queue TTL
    # Quorum 队列目前不支持优先级,包括消费者优先级
    
    联邦交换机 federation Exchange
    # 提供了跨地域的集群间消息同步 ...
    
    # -------------------------------------------------- 基础组件
    
    # Server
    # Connection
    # Channel
    # Virtual Host
    # Exchange
    # Message
    # Binding
    # Routing Key
    # Binding Key
    # Message Queue
    # Exchange Type (direct topic fanout)
    # Producer、Consumer
    # Publisher、Subscriber (topic Exchange Type)
    
    # -------------------------------------------------- 相关端口
    
    4369        # epmd,RabbitMQ 节点和 CLI 工具使用的辅助发现守护进程
    5672,5671   # 由 AMQP 0-9-1 和 1.0 客户端使用
    15672       # HTTP API、管理UI、rabbitmqadmin(仅当启用管理插件时)
    61613,61614 # 没有和有 TLS 的 STOMP 客户端(仅当启用了 STOMP 插件时)
    1883,8883   # 若启用了MQTT 插件
    15674       # STOMP-over-WebSockets 客户端(仅当启用 Web STOMP 插件时)
    15675       # MQTT-over-WebSockets 客户端(仅当启用 Web MQTT 插件时)
    15692       # Prometheus 指标(仅当启用Prometheus 插件时)
    25672:
    # 用于节点间和 CLI 工具通信(Erlang 分发服务器端口)并从动态范围分配(默认限制为单个端口,计算为: AMQP端口+20000)
    # 除非确实需要这些端口上的外部连接(例如集群使用联合或在子网外的机器上使用CLI工具),否则不应公开这些端口
    35672-35682:
    # 由 CLI 工具(Erlang 分发客户端端口)用于与节点通信
    # 并从动态范围(计算为服务器分发端口 + 10000 到服务器分发端口 + 10010)分配
    
    

    Theory

    
    # -------------------------------------------------- fanout 伪代码
    
    Channel channel = connection.createChannel();                   # 在rabbitmq中创建一个信道
    channel.exchangeDeclare("exchangeName", "fanout");              # 创建一个type为fanout的交换器    
    channel.queueDeclare("queueName");                              # 创建一个队列
    channel.queueBind("queueName", "exchangeName", "routingKey");   # 将队列和交换器绑定
    
    # -------------------------------------------------- direct 伪代码
    
    Channel channel = connection.createChannel();                   # 在rabbitmq中创建一个信道
    channel.exchangeDeclare("exchangeName", "direct");              # 创建一个type为direct的交换器
    channel.queueDeclare("queueName");                              # 创建一个队列,Tips: 一个队列可以指定多个路由键
    channel.queueBind("queueName", "exchangeName", "zhangsna");     # 绑定并设置路由键 (队列一)
    channel.queueBind("queueName", "exchangeName", "lisi");         # 绑定并设置路由键 (队列一)
    channel.queueBind("queueName", "exchangeName", "wangwu");       # 绑定并设置路由键 (队列一)
    
    # 当生产者发送了一条 routeting 为 zhangsan 的消息到交换器中,交换器在分发的时候只会把消息分发到队列一里去
    # 因为交换器在 routeting 匹配时只匹配到了队列一,因此其他队列不会收到消息 ...
    
    # -------------------------------------------------- Topic 说明
    
    # Topic 与 direct 类型的交换机的主要区别为: 判断 routeing key 时是模糊匹配 ...
    # Rabitmq 自定义了一套匹配规则,这里假设生产者发送的消息中 routing Key 为 wiki.imooc.com
    # 那么当交换器为 topic 类型时,想要获取到这条消息可以用 * 作为通配符来指定 routingKey,如: *.*.com、*.imooc.*、*wiki.imooc.*
    # 同样也可以使用 # 作为通配符来指定路由键: wiki.#、#.com
    
    # Tips:
    # 在上面的通配列子中,路由键以 . 为分隔符,每个分隔符代表一个单词
    # 通配符 * 只可匹配一个单词、通配符 # 可匹配多个单词 ...
    # * 可在 routing Key 和 binding Key 使用,而 # 只能用于 Routing Key
    
    # -------------------------------------------------- headers 说明
    
    # 类型为 headers 的交换器与前三种匹配方式完全不同
    # 它不依赖于 bindingKey 和 routingKey,而是在绑定队列与交换器的时候指定一个键值对 ...
    # 当交换器在分发消息时会先解开消息体里的 headers 数据,然后判断里面是否有相应的键值对,若有则匹配成功,并将消息分发到队列中
    # 这种交换器类型在性能上相对较差,实际很少用 ...
    
    # --------------------------------------------------------------------------------
    
    # 消息中间件的吞吐量始终会受到硬件的限制
    # 以网卡带宽为例,如果单机单网卡带宽为1Gbps,若要达到百万级的吞吐,则消息体大小不得超过(1Gb/8)/100W,即约等于134B
    # 换句话说如果消息体大小超过 134B 就不可能达到百万级别的吞吐。这种计算方式同样可以适用于内存和磁盘
    # 在实际生产中通常使用 kafka 作为消息传输的数据管道,rabbitmq 作为交易数据的传输管道,主要取舍因素为是否存在丢数据的可能
    # kafka 适用于高吞吐量场景,rabbitmq 适用于对可靠性要求高的场景(兔子支持消息的全局有序)
    
    # 网络是不可靠的,消费者在处理消息的过程中也会意外挂掉,导致未处理成功的消息丢失
    # 因此 AMQP 模块提供消息确认(Message Acknowledgements)机制:
    # 当消息从队列中投递给消费者后不会立即从队列删除,直到它收到来自消费者的确认回执(Acknowledgement)后才完全从队列删除 ...
    # AMQP 0-9-1 规范给出两种建议:
    #   1.自动确认模式: 当消息代理 broker 将消息发送给应用后立即删除(使用 AMQP 方法:basic.deliver 或 basic.get-ok)
    #   2.显式确认模式: 待应用 application 发送一个确认回执 acknowledgement 后再删除消息 (使用 AMQP 方法:basic.ack)
    
    # 在某些情况下,例如当消息无法被成功路由时(无法从交换机分发到队列)或许会被返回给发布者并被丢弃
    # 或者,如果消息代理执行了延期操作,消息会被放入所谓的死信队列。此时消息发布者可选择某些参数来处理这些特殊情况
    
    
    展开全文
  • 消息队列与AMQP协议

    千次阅读 2018-01-29 18:21:08
    消息队列(Message Queue,简称MQ)提供异步通信协议,可以实现进程间通信或同一进程不同线程间的通信。其中‘消息’是指包含必要信息的数据。消息的发送者发送完数据后,立即返回,消息被存储在消息队列当中,对这个...

    一、 消息队列

    消息队列(Message Queue,简称MQ)提供异步通信协议,可以实现进程间通信或同一进程不同线程间的通信。其中‘消息’是指包含必要信息的数据。消息的发送者发送完数据后,立即返回,消息被存储在消息队列当中,对这个消息感兴趣的消费者会订阅消息并接收并处理它。
    使用消息队列的好处如下:

    1、 应用解耦

    消息是与平台和语言无关的,消息队列可以应对多变的产品变更。
    

    2、 异步通信

    可以缩短请求等待的时间,使用专门处理请求的消费者来执行,提高WEB页面的吞吐量,
    尤其是瞬间发生的高流量情况,消息队列非常有助于顶住访问的压力
    

    3、数据持久化

    未完成的消息不会因为某些故障而丢失。
    

    4、 送达保证

    消息队列提供的冗余机制保证了消息确实能被处理,除非消费者明确表示已经出来完这个消息,否则这个消息可以被放回队列中以备其他消费者出来。    
    

    二 、AMQP协议

    1、概述

    1.1 什么是AMQP

    AMQP,即Advanced Message Queuing Portocol,高级消息队列协议。
    该协议使得遵从该规范的客户端应用和消息中间服务器的全功能互操作成为可能,
    它的设计初衷是为了拜托商业MQ高额费用和不同MQ供应商的接口不统一的问题。
    消息发送与接收的双方遵守这个协议可以实现异步通信,这个协议约定了消息的格式和工作方式
    

    1.2 为什么使用AMQP

    在分布式的系统中,子系统如果使用socket进行通信,有很多问题需要解决
    1)消息的发送者和接收者如何维持这个连接,如果一方中断,这期间的数据如何防止丢失?
    2)如何降低发送者和接收者的耦合
    3)如何让优先级高的接收者接收消息
    4)如何做到负载均衡
    5)如何将消息发送给相关的接收者,如果接收者订阅了不同的数据,如何正确的分发到接受者。
    6)如何保证接收者接到了正确的或者是有序的数据。
    7)如何做到可扩展,将通信模块发到集群上去。
    AMQP可以解决这些问题。
    

    2 、AMQP的模型与原理

    2.1 AMQP中包含的主要元素

    生产者(producer):向Exchage发布消息的应用
    消费者(Consumer):从消息队列中消费消息的应用。
    消息队列(Message Queue):服务器组件,用于保存消息,知道发送给消费者
    消息(Message):传输的内容,消息实际上包含了两部分的内容
        1.有效载荷(Payload),也就是要传输的数据,数据类型可以纯文本,也可以是JSON
        2.标签(Lable),它包含交换机的名字和可选的主题(topic)标记等。
    交换器(Exchage):路由组件,接收生产者发送的消息,并将消息路由转发给消息队列
    虚拟主机(Virtual Host):一批交换器,消息队列和相关对象。虚拟主机共享相同身份认证和加密环境独立的独立服务器域。
    连接(Connection):一个网络连接,比如TCP/IP套接字连接。
    信道(Channel):多路复用连接中的一条独立的双向数据流通道,为会话提供物理传输介质。
    绑定器(Binding):消息队列和交换器直接的关联。
    

    2.2 AMQP的工作流程

    这里写图片描述

    2.3 AMQP是如何建立通信的

    1)建立连接Connection。由生产者和消费者创建连接,连接到broker(消息代理)的物理节点上。
    2)建立Channel。Channel是建立在Connection之上的,一个Connection可以建立多个 Channel,
      producer连接Virtual Host 建立Channel,Consumer连接到相应的queue上建立Channel。
    3)发送消息。由Producer发送消息到Broker中的exchange中。
    4) 路由转发。exchange收到消息后,根据一定的路由策略,将消息转发到相应的queue中去。
    5)消息接收。Consumer会监听相应的queue,一旦queue中有可以消费的消息,
      queue就将消息发送给Consumer端。
    6)消息确认。当Consumer完成某一条消息的处理之后,需要发送一条ACK消息给对应的Queue。
      Queue收到ACK信息后,才会认为消息处理成功,并将消息从Queue中移除;
      如果在对应的Channel断开后,Queue没有收到这条消息的ACK(消息回应)信息,
      该消息将被发送给另外的Channel。 
      至此一个消息的发送接收流程走完了。消息的确认机制提高了通信的可靠性。
    

    2.4 技术术语

    连接(Connection):一个网络连接,比如TCP/IP套接字连接。
    会话(Session):端点之间的命名对话。在一个会话上下文中,保证“恰好传递一次”。
    信道(Channel):多路复用连接中的一条独立的双向数据流通道。为会话提供物理传输介质。
    客户端(Client):AMQP连接或者会话的发起者。AMQP是非对称的,客户端生产和消费消息,服务器存储和路由这些消息。
    服务器(Server):接受客户端连接,实现AMQP消息队列和路由功能的进程。也称为“消息代理”。
    端点(Peer):AMQP对话的任意一方。一个AMQP连接包括两个端点(一个是客户端,一个是服务器)
    搭档(Partner):当描述两个端点之间的交互过程时,使用术语“搭档”来表示“另一个”端点的简记法。
                   比如我们定义端点A和端点B,当它们进行通信时,端点B是端点A的搭档,端点A是端点B的搭档。
    片段集(Assembly):段的有序集合,形成一个逻辑工作单元。
    段(Segment):帧的有序集合,形成片段集中一个完整子单元。
    帧(Frame):AMQP传输的一个原子单元。一个帧是一个段中的任意分片。
    控制(Control):单向指令,AMQP规范假设这些指令的传输是不可靠的。
    命令(Command):需要确认的指令,AMQP规范规定这些指令的传输是可靠的。
    异常(Exception):在执行一个或者多个命令时可能发生的错误状态
    类(Class):一批用来描述某种特定功能的AMQP命令或者控制。
    消息头(Header):描述消息数据属性的一种特殊段。
    消息体(Body):包含应用程序数据的一种特殊段。消息体段对于服务器来说完全透明——服务器不能查看或者修改消息体。
    消息内容(Content):包含在消息体段中的的消息数据。
    交换器(Exchange):服务器中的实体,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
    交换器类型(Exchange Type):基于不同路由语义的交换器类。
    消息队列(Message Queue):一个命名实体,用来保存消息直到发送给消费者。
    绑定器(Binding):消息队列和交换器之间的关联。
    绑定器关键字(Binding Key):绑定的名称。一些交换器类型可能使用这个名称作为定义绑定器路由行为的模式。
    路由关键字(Routing Key):一个消息头,交换器可以用这个消息头决定如何路由某条消息。
    持久存储(Durable):一种服务器资源,当服务器重启时,保存的消息数据不会丢失。  
    临时存储(Transient):一种服务器资源,当服务器重启时,保存的消息数据会丢失。
    持久化(Persistent):服务器将消息保存在可靠磁盘存储中,当服务器重启时,消息不会丢失。
    非持久化(Non-Persistent):服务器将消息保存在内存中,当服务器重启时,消息可能丢失。
    虚拟主机(Virtual Host):一批交换器、消息队列和相关对象。
                            客户端应用程序在登录到服务器之后,可以选择一个虚拟主机。
    

    2.5 应用场景

    AQMP是实现消息机制的一种协议,消息队列主要有以下几种应用场景:
    

    1. 异步处理

    比如公司新入职一个员工,需要开通系统账户,有几件事情要做,开通系统账户,发短信通知用户,发邮件给员工,在公司内部通讯系统中发送消息给员工。其中发短信,发邮件,发内部通讯系统消息,这三件事情可以串行,也可以并行,并行的好处就是可以提高效率。这时候可以使用MQ来实现运行。

    2. 应用解耦

    在公司内部系统中,有人事系统,OA系统,财务系统,外围应用系统等等,当人事发生变动的时候(离职入职调岗),人事系统需要将这些变动通知给其他系统,这时只需人事系统发送一条消息,各个外围系统订阅该消息,就可得知人事变动,与实时服务调用相比,如果人事系统挂掉,各个外围系统不会受到影响,继续运行。

    3. 流量缓冲

    在有些流量会瞬间暴增的场景下,如秒杀,为了防止流量突然增大而使得应用挂掉,可以引入MQ,将请求存入MQ中,如果超过了MQ的长度,就把请求丢弃掉,这样来限制流量。

    4. 日志处理

    将消息队列引入到日志处理中,如kafka的应用,解决了大量日志的传输问题。日志客户端负责采集日志数据,并定期写入kafka队列,kafka负责接收,存储和转发日志,日志处理系统订阅并消费kafka中的日志数据。

    展开全文
  • MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的“轻量级”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以...
  • 本文主要介绍了两种java实现消息队列的方式,利用Spring消息模板发送消息和Apache ActiveMQ官方实例发送消息,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • RabbitMQ 是高级消息队列协议(AMQP)的开源消息代理软件。 RabbitMQ 服务器是用 Erlang 语言编写的,消息系统允许软件、应用相互连接和扩展。这些应用可以相互链接起来组成一个更大的应用,或者将用户设备和数据...
  • 基于消息队列遥测传输协议的智能家居消息中间件设计.pdf
  • AMQP(高级消息队列协议)是一个异步消息传递所使用应用层协议规范,为面向消息中间件设计,基于此协议的客户端与消息中间件可以无视消息来源传递消息,不受客户端、消息中间件、不同的开发语言环境等条件的限制;...
  • 02 | 该如何选择消息队列?

    千次阅读 2020-01-19 13:55:40
    用于比较常见的开源的消息队列中间件,从而根据自身业务做技术选型。
  • 本人业余时间开发,目前实现了Tcp通信方式,预留了http接口,有兴趣的同学可以自己实现
  • [1]AMQP(高级消息队列协议) ----入门

    千次阅读 2016-07-02 23:09:33
    接触AMQP协议已经有一段时间了,这个协议比想象的中的要复杂一些,特别是针对AMQP-1-0以前的版本。具体的概念,网上可以搜索到很多的资料,本文借花献佛,让读者对AMQP协议有一个大概的了解。重点是在后续章节的关于...
  • 消息队列(MQ)

    千次阅读 2021-11-13 14:20:18
    一、消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: 当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候。...
  • 消息中间件(消息队列

    万次阅读 2022-02-17 13:52:30
    消息中间件
  • 消息中间件(消息队列)介绍

    千次阅读 2022-02-27 17:19:08
    文章目录一、概述二、消息中间件的组成三、消息中间件模式分类3.1、点对点(PTP)模式3.2、发布订阅(Pub/Sub)模式3.3、小结四、消息中间件的...、日志采集4.5、消息通讯五、消息中间件的优点六、消息中间件常用协议...
  • 消息队列的介绍及配置

    千次阅读 2022-01-11 11:34:57
    一、消息队列详解 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为:当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候 主要...
  • 其实消息队列没有那么神秘,我们这样想一下,用户访问网站,最终是要将数据以HTTP的协议的方式,通过网络传输到主机的某个端口上的。 那么,接收数据的方式是什么呢?自然是端口监听啦。 那消息队列是什么就很好解释...
  • 消息队列

    千次阅读 多人点赞 2019-09-19 21:42:59
    消息队列”是在消息的传输过程中保存消息的容器,当我们需要使用消息的时候可以取出消息供自己使用。 消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用...
  • 消息协议则是指用于实现消息队列功能时所涉及的协议。按照是否向行业开放消息规范文 档,可以将消息协议分为开放协议和私有协议。常见的开放协议有 AMQP, MQTT STOMP,XMPP 等。有些特殊框架(如 Red Kafka ZeroMQ )...
  • memche消息队列的原理就是在...方便实现队列的轻量级队列服务器是:starling支持memcache协议的轻量级持久化服务器https://github.com/starling/starlingBeanstalkd轻量、高效,支持持久化,每秒可处理3000左右的队列...
  • 消息队列”是在消息的传输过程中保存消息的容器。 “消息”是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串;也可以更复杂,可能包含嵌入对象。 消息被发送到队列中。“消息队列”是在...
  • 消息队列RabbitMQ详解

    千次阅读 2020-06-03 11:22:40
    我们要给消息队列中存取内容,就要连接消息中间件的服务器; 当消息发送者发送消息以后,将由消息代理(服务器)接管,消息代理保证消息传递到指定目的地。 3.消息队列主要有两种形式的目的地 1.队列...
  • 常用6种消息队列介绍和对比

    千次阅读 2021-03-25 14:37:55
    消息队列是分布式应用间交换信息的重要组件,消息队列可驻留在内存或磁盘上, 队列可以存储消息直到它们被应用程序读走。 通过消息队列,应用程序可以在不知道彼此位置的情况下独立处理消息,或者在处理消息前不需要...
  • RabbitMQ消息队列

    千次阅读 2021-12-09 23:30:06
    MQ(message queue),从字面意思上看,本质是个队列,FIFO 先入先出,只不过队列中存放的内容是message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ 是一种非常常见的上下游“逻辑解耦+...
  • php消息队列框架httpsqs

    2019-03-21 11:00:46
    HTTPSQS(HTTP Simple Queue Service)是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务,使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。源代码不超过700行,整个软件不超过900KB...
  • 消息队列MQ与微消息队列MQTT

    千次阅读 2019-11-10 20:24:35
    文章目录为什么要使用MQ消息队列1. 解耦(可用性)2. 流量削峰3. 数据分发缺点MQ对比传统消息队列RocketMQ和微消息队列MQTT对比 https://www.jianshu.com/p/15081799d66b 为什么要使用MQ消息队列 1. 解耦(可用性) ...
  • http://127.0.0.1:8000/getList queueName">一个NodeJS和redis做的基于http协议使用的队列 做了点小修改 支持多个队列和post提交 原github地址:https://github.com/lnmp/nodemq 使用方法: 在安装好redis和nodejs...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 285,826
精华内容 114,330
关键字:

消息队列协议