消息中间件(三)

时间:2021-12-14 04:13:13

一.     AMQP协议

1.概述

    AMQP: Advanced Message Queuing Protocol

    是一个提供统一消息服务的应用层标准高级消息队列协议,一种应用层协议的开放标准,面向消息,支持不同语言和不同的产品

    经典实现:RabbitMQ

2. 角色

a)生产者

消息的创建者,发送到amqp的消息中间件

b) 消费者

连接到amqp的消息中间件,订阅到队列上,进行消息的消费。分为持续订阅(basicConsumer)和单条订阅(basicGet)

c) 消息

包括有效载荷和标签。有效载荷就是要传输的数据。标签描述有效载荷的属性(rabbitmq用标签来决定谁获得当前消息。消费者只能拿到有效载荷)

d) 信道

虚拟的连接,建立在真实的tcp连接之上的。信道的创建没有限制的。

e) 交换器/队列/绑定/路由键

消息中间件(三)

1). 队列通过路由键(routing key,某种确定的规则)绑定到交换器,生产者把消息发送到了交换器,交换器根据绑定的路由键将消息路由到特定的队列,订阅了队列的消费者进行接收。

i.如果消息到达了无人订阅的队列,消息会无限制的一直等待。

ii.RabbitMQ中的队列默认为无限长度。

iii.多个消费者订阅到同一个队列,消息会以轮询的方式发出,且每个消息只会发送给一个消费者。

iv.消息路由到了不存在的队列,会舍弃这条消息,消息会丢失。

2).消息的确认机制

消费者收到的每一条消息都必须进行确认。

i.自动确认:

消费者在声明队列时,指定autoAck参数,true。


ii.自行确认:

消费者在声明队列时,指定autoAck参数,false。

自行确认模式下,rabbitmq会等到消费者显示的发回一个ack信号才会删除消息。有足够时间让消费者处理消息,直到消费者显示调用basicAck为止。


3).RabbitMq中消息分为两种状态:

i.等待投递的消息

ii.已经投递,但是没有收到ACK信号的消息

R如果此时消费者断联,则该消息会被重新入队,投递给下一个消费者。(没有收到ACK的消息是没有超时时间的)

4).RabbitMQ拒绝消息

i.消费者断联时,队列会认为消费者拒绝了消息

ii.消费者使用reject命令拒绝消息。(reject=ture队列会重新分发,false队列会删除掉该消息)

iii.nack命令,批量拒绝

5).RabbitMQ的队列

i.创建队列

(生产/消费)declareQueue。消费者订阅了队列,不能再声明队列了。相关参数(

    exclusive 队列为应用程序私有,

    auto-delete 最后一个消费者取消订阅时,队列会自动删除,

    durable 队列持久化 )

 Declare时的passive参数---检查队列是否存在。

6) .RabbitMQ的四种交换器

i.   direct: 路由键完全匹配时,消息投放到对应队列。Amqp实现都必须有一个direct交换器(默认交换器),名称为空白字符。队列不声明交换器,会自动绑定到默认交换器,队列的名称作为路由键。

ii.   Fanout:可以理解为广播

iii.   Topic:主题,使来自不同源头的消息到达同一个队列

iv.   Headers: 匹配消息头,其余与direct一样,实用性不大

7). 路由键中的“*”和“#”

f) 虚拟主机

Vhost,真实rabbitmq服务器上的mini型虚拟的mq服务器。有自己的权限机制。Vhost提供了一个逻辑上的分离,可以区分客户端,避免队列和交换器的名称冲突。RabbitMq包含了一个缺省的vhost :“/”,用户名guest,口令 guest(guest用户只能在本机访问)。

4.消息持久化

a.消息持久化的条件

i.队列必须持久化

ii.交换器必须持久化

iii.消息的投递模式必须是int型

b.消息持久化的性能问题

会导致性能整体下降10倍左右


5. AMQP   &   JMS


      

JMS

AMQP

定义

Java api

协议

Model

P2P

Pub/Sub

Direct

Fanout

Topic

headers

支持消息类型

5种

Byte[]

自行消息序列化,Json化

综合评价

Java系统,模型满足要求,跨平台较差

协议,天然跨平台,跨语言



6. 事务/发送方确认

a.  事务    

生产者不知道消息是否真正到达RabbitMq,也就是说发布操作不返回任何消息给生产者。
AMQP协议层面为我们提供的事务机制解决了这个问题,但是事务机制本身也会带来问题:
i、严重的性能问题
ii、使生产者应用程序产生同步

b. 发送方确认

RabbitMQ团队为我们拿出了更好的方案,即采用发送方确认模式,该模式比事务更轻量,性
能影响几乎可以忽略不计。

发送方确认模式的机制。


注意:发送方确认模式和消费者对消息的确认是不同的。



https://blog.csdn.net/dervish0927/article/details/79935573