240124 - mq - 概念解释

什么是消息队列RabbitMQ版？
云RabbitMQ版是基于高可用分布式存储架构实现的AMQP 0-9-1协议的消息产品
云RabbitMQ版兼容开源RabbitMQ客户端,解决开源各种稳定性痛点(例如消息堆积,脑裂等问题),同时具备高并发,分布式,灵活扩缩容等优势.

【Queue】消息队列,每个消息都会被投入到一个或多个Queue里 存储消息的缓冲区
【Exchange】将消息路由到queue的组件
生产者将消息发送到Exchange,由Exchange将消息路由到一或多Queue中. Exchange根据消息的属性或内容路由消息
【生产者】消息发送者,即发送消息的程序
【消费者】消息消费者,即接收消息的程序
【Alternate Exchange】备份Exchange,简称AE,用于接收配置了备份Exchange的Exchange路由失败的消息
【Arguments】Queue的参数,可用于设置死信Exchange,消息过期时间,死信Routing key等
【Auto Delete】自动删除属性,对于设置了自动删除的Exchange,如果绑定到该Exchange的最后一个Queue解除绑定,那么该Exchange将会自动删除. 对于设置了自动删除的Queue,如果订阅该Queue的最后一个消费端取消订阅后,那么该Queue将会自动删除
【Binding】一套绑定规则,用于告诉Exchange消息应被存储到哪个Queue.它的作用是把Exchange和Queue按照路由规则绑定起来.
【Binding Key】用于告知Exchange应将消息投递到哪些Queue中
【Channel】在客户端的每个物理TCP连接里,可建立多个Channel,每个Channel代表一个会话任务.
【Connection】TCP连接,生产者或消费者与云消息队列RabbitMQ版间的物理TCP连接.
【Internal】内建类型,该类型的Exchange用于Exchange之间的绑定
【Message ID】Message ID(消息标识符)是消息的可选属性,类型为short string. Message ID在业务上通常被设置为唯一,适用于追踪和识别销售单,工单等需要保证消息唯一的场景. 云RabbitMQ服务端不会对消息进行幂等处理. 如需实现消息幂等,即如果消息重试多次,消费端对该重复消息消费多次与消费一次的结果是相同的,且多次消费没有对系统产生副作用,在为每条消息设置唯一Message ID的基础上,还需在云RabbitMQ的Consumer客户端对消息进行幂等处理
【Routing Key】生产者在向Exchange发送消息时,需指定一个Routing Key来设定该消息的路由规则. Routing Key需与Exchange类型及Binding Key联合使用才能生效. 一般,生产者在向Exchange发送消息时,可通过指定Routing Key来决定消息被路由到哪个或哪些Queue
【死信Exchange】用于路由死信消息的Exchange. 死信Exchange会根据Binding Key, 死信Routing Key, Header属性将死信消息投递至死信Queue. 死信Exchange可以是任何一种常见类型的Exchange,例如Direct Exchange
【死信Routing Key】死信消息的路由规则. 如不设置死信消息的Routing Key,则死信消息的Routing Key默认为消息本身的Routing Key
【死信消息】被重新发送到死信Exchange的消息.
消息变成死信消息的可能原因:
requeue参数被设置为false,消费者使用basic.reject或basic.nack否定应答(NACK)消息
消息重试次数超过16次,消息重试失败
消息过期,即消息在Queue中存在的时间超过了设置的消息存活时间
【死信Queue】死信Exchange绑定的Queue,用于存储死信消息
【Vhost】虚拟主机(Virtual Host),用作逻辑隔离,分别管理各自的Exchange,Queue和Binding,使得应用安全地运行在不同的Vhost实例上,相互之间不会干扰. 一个实例下可有多个Vhost,一个Vhost里面可有若干个Exchange和Queue. 生产者和消费者连接云RabbitMQ需指定一个Vhost
【消息存活时间】消息在Queue中的有效期. 某条消息在Queue中的留存时间超过配置的消息存活时间时,则该消息过期. 消息存活时间的值须为非负整型数,单位为毫秒. 例如,某条消息的存活时间的值是1000,则代表该消息最多会在Queue中存活1秒
【延时消息】生产者将消息发送到云RabbitMQ版服务端,但并不期望这条消息立马投递,而是延迟一定时间后才投递到消费者进行消费,即延时消息
【永久性】在服务器重启之后Queue,Exchange以及相应Binding仍然存在的现象

【Connection】Connection是物理TCP连接.
Connection将应用与云RabbitMQ连接在一起. Connection会执行认证,IP解析,路由等底层网络任务.
应用与云RabbitMQ完成Connection建立大约需要15个TCP报文交互,因而会消耗大量的网络资源和云RabbitMQ资源.
大量Connection会对云RabbitMQ造成压力,甚至触发云RabbitMQ SYN洪水攻击防护,导致云RabbitMQ无响应,影响业务

【Channel】Channel是物理TCP连接中的虚拟连接.
应用通过Connection与云MQ建立连接后,所有AMQP协议操作(例如创建队列,发送消息,接收消息等)都会通过Connection中的Channel完成
Channel可复用Connection,一个Connection下可建多个Channel
Channel不能脱离Connection独立存在,而必须存活在Connection中.
当某个Connection断开时,该Connection下的所有Channel都会断开.
当大量应用需要与云MQ建立多个连接时,建议使用Channel来复用Connection,从而减少网络资源和云RabbitMQ资源消耗
使用建议:
保持Connection长连接,勿频繁开启或关闭Connection.如需要频繁开启或关闭连接,请使用Channel. 单实例开启Connection或Channel的接口限制，请参见使用限制。
Connection数量较少而消费的数据量较大时,可能会出现消费倾斜问题,可在保证每个消费者Connection数一致的同时,增加每个消费者的Connection数或增加消费者数量. 建议所有消费者的Connection之和大于30
多个进程可共享同一个Connection,共享时请不要频繁建立和关闭Connection,否则可能会出现ChannelNotFind错误
Producer和Consumer分别使用不同的Connection进行消息发送和消费

【Exchange】Exchange是云mq的消息路由代理. 生产者向云MQ发送消息时,不会直接将消息发送到Queue,而是先将消息发送到Exchange,由Exchange将消息路由到一个或多个Queue. Exchange根据Binding Key, Routing Key, Headers属性路由消息

【Direct Exchange】
路由规则: Direct Exchange根据Binding Key和Routing Key完全匹配的规则路由消息
使用场景: Direct Exchange适用于通过简单字符标识符区分消息的场景. Direct Exchange常用于单播路由
匹配示例: Direct Exchange根据Binding Key和Routing Key完全匹配的规则路由消息的示例如下：

【Topic Exchange】
路由规则: Topic Exchange根据Binding Key和Routing Key通配符匹配的规则路由消息. Topic Exchange支持的通配符包括()和(#).
星号()代表一个英文单词(例如cn); 井号(#)代表零个,一个或多个英文单词,英文单词间通过英文句号(.)分隔,例如cn.zj.hz
使用场景: Topic Exchange适用于通过通配符区分消息的场景. Topic Exchange常用于多播路由. 例:使用Topic Exchange分发有关于特定地理位置的数据
路由示例: Topic Exchange根据Binding Key和Routing Key通配符匹配的规则路由消息的示例如下:

【Fanout Exchange】
路由规则: Fanout Exchange忽略Routing Key和Binding Key的匹配规则将消息路由到所有绑定的Queue
使用场景: Fanout Exchange适用于广播消息的场景. 例如,分发系统使用Fanout Exchange来广播各种状态和配置更新
路由示例: Fanout Exchange忽略Routing Key和Binding Key的匹配规则将消息路由到所有绑定的Queue的示例如下

【Headers Exchange】
路由规则: Headers Exchange可被视为Direct Exchange的另一种表现形式
Headers Exchange可像Direct Exchange一样工作,不同之处在于Headers Exchange使用Headers属性代替Routing Key进行路由匹配
在绑定Headers Exchange和Queue时,可设置绑定属性的键值对. 在向Headers Exchange发送消息时,设置消息的Headers属性键值对
Headers Exchange将根据消息Headers属性键值对和绑定属性键值对的匹配情况路由消息
匹配算法由一个特殊的绑定属性键值对控制. 该属性为x-match,只有以下两种取值:
all: 所有除x-match以外的绑定属性键值对必须和消息Headers属性键值对匹配才会路由消息
any: 只要有一组除x-match以外的绑定属性键值对和消息Headers属性键值对匹配就会路由消息
以下两种情况下,认为消息Headers属性键值对和绑定属性键值对匹配:
消息Headers属性的键和值与绑定属性的键和值完全相同
消息Headers属性的键和绑定属性的键完全相同,但绑定属性的值为空
使用场景: Headers Exchange适用于通过多组Headers属性区分消息的场景. Headers Exchange常用于多播路由. 例:涉及到分类或者标签的新闻更新
使用示例: Headers Exchange根据消息Headers属性和Binding Headers属性的匹配规则路由消息的示例如下：

【JMS Queue Exchange】除AMQP协议约定的Exchange外,云MQ还支持JMS Queue Exchange.
JMS Queue Exchange本质上就是Direct Exchange.
云消息队列 RabbitMQ 版通过JMS Queue Exchange来实现JMS规范约定的Queue
说明: 该类Exchange只能通过SDK创建。
路由规则: JMS Queue Exchange根据Binding Key和Routing Key完全匹配的规则路由消息
使用场景: JMS Queue Exchange适用于通过简单字符标识符区分消息的场景。JMS Queue Exchange常用于单播路由。
使用示例: JMS Queue Exchange根据Binding Key和Routing Key完全匹配的规则路由消息的示例如下：

【JMS Topic Exchange】除AMQP协议约定的Exchange外,云MQ还支持JMS Topic Exchange
JMS Topic Exchange本质上就是Topic Exchange. 云MQ通过JMS Topic Exchange来实现JMS规范约定的Topic
路由规则: JMS Topic Exchange根据Binding Key和Routing Key通配符匹配的规则路由消息.
JMS Topic Exchange支持*和# *代表一个英文单词(例如cn) #代表零个,一个或多个英文单词,英文单词间通过英文句号(.)分隔(例如cn.zj.hz)
使用场景: JMS Topic Exchange适用于通过通配符区分消息的场景. JMS Topic Exchange常用于多播路由. 例:使用JMS Topic Exchange分发有关于特定地理位置的数据
使用示例: JMS Topic Exchange根据Binding Key和Routing Key通配符匹配的规则路由消息的示例如下：

【x-delayed-message Exchange】
云MQ兼容开源RabbitMQ以插件形式支持的x-delayed-message Exchange.
无需安装该插件,只需声明该类Exchange,并自定义消息的Header属性x-delay来指定消息延时投递的时间段,单位为毫秒.
消息将在x-delay定义的时间段后被投递到对应的Queue
路由规则: x-delayed-message Exchange根据扩展字段x-delayed-type指定的Exchange类型确定路由规则。支持x-delayed-message的Exchange类型如下：
Direct Exchange
Topic Exchange
Fanout Exchange
Headers Exchange
JMS Queue Exchange
JMS Topic Exchange
使用场景: x-delayed-message Exchange适用于需要延时投递消息的场景
使用示例: x-delayed-message Exchange根据x-delayed-type指定的Exchange类型的路由规则路由消息. 以x-delayed-type指定为Direct类型为例,Direct Exchange根据Binding Key和Routing Key完全匹配的规则路由消息的示例如下:

【x-consistent-hash Exchange】云MQ兼容开源RabbitMQ以插件形式支持的x-consistent-hash Exchange. 无需装插件,只需声明该类Exchange
说明: x-consistent-hash Exchange暂不支持基于hash-property的方式进行路由,即不支持按照message id, correlation id、timestamp的方式计算哈希路由
路由规则: x-consistent-hash Exchange支持基于Routing Key或Header值两种方式进行路由。Exchange收到消息后，会根据消息的Routing Key或Header值进行Hash运算，由计算的Hash值决定消息路由到哪个绑定的Queue中。
同一Routing Key或Header值计算的Hash值相同，因此，相同Routing Key或Header值的消息会被路由到同一个Queue中。
使用Header值的方式进行路由匹配时，需要通过hash-header字符串声明Exchange、声明要使用的Header。同时发布的消息需要包含hash-header所选的Header，若未包含指定的Header，则全部消息将被路由到同一个任意队列中。
若Routing Key和hash-header参数同时定义，则以hash-header参数值为输入进行Hash运算。
x-consistent-hash Exchange绑定Queue时，Binding Key需要设置为1~20的数字，表示该Queue的权重。数值越大权重越大，分发消息时接收到的消息越多。
当Queue的Binding Key大于20时，权重会视为20。
当存在重复绑定时，只有第一个符合要求的绑定（绑定值为正整数）有效；修改Queue的权重时，请先删除已有的绑定关系。
使用场景: x-consistent-hash适合按照权重对消息进行划分的场景。
使用示例: x-consistent-hash Exchange根据消息的指定方式计算哈希进行路由。Exchange上绑定有不同权重的Queue，并根据Queue的权重将消息分发到不同的Queue中。本示例以基于Routing Key方式计算路由规则为例。