消息队列 RocketMQ
2022-06-19 19:56:37 0 举报AI智能生成
阿里云RocketMQ
作者其他创作
大纲/内容
定义
消息队列RocketMQ版最小授权粒度可以为某个Topic 的具体操作权限，例如创建Topic，删除Topic ，更新Topic
消息队列RocketMQ 不支持传递路由，例如地域A到地域B再到地域C，地域A的消息不会经过地域B再到地域C，如果有需要请直接创建地域A到地域C的路由
消息队列RocketMQ 的全球消息路由功能依托阿里云优质基础设置实现的高速通道专线，高效的实现不同地域之间的消息同步复制
调用API时阿里云会对每个API请求通过签名进行身份验证；签名信息包括
SignatureMethod
SignatureVersion
SignatureNonce
Signature
RocketMQ 支持普通消息/顺序消息/事务消息的生产者消费者和Spring集成
一条消息的完整链路包含生产者，服务端，消费者三个角色，每个角色处理消息的过程中都会在轨迹链路中增加相关的信息，将这些信息汇聚即可获取任意消息当前的状态
框架
nameServer
是一个几乎无状态节点，可集群部署，在消息队列 RocketMQ 版中提供命名服务，更新和发现Broker服务
Broker
消息中转角色，负责存储消息，转发消息
Broker 启动后需要完成一次将自己注册到Name Serer的操作；随后每隔30s定期向Name Server 上报Topic 路由信息
Consumer 既可以从Master Broker 订阅，也可以从Slave Broker订阅消息，订阅规则由Broker配置决定
Master Broker
一个Master Broker 可以对应多个Slave Broker
Slave Broker
但是一个 Slave Broker 只能对应一个Master Broker
生产者
与name Server 集群中的其中一个节点（随机） 建立长连接 ，定期从Name Server 读取 Topic 路由信
并向提供Topic 服务的Master Broker 建立长链接
定时向Master Broker 发送心跳
消费者
与Name Server 集群中的其中一个节点（随机） 建立长链接
定期从Name Server 拉取 Topic 路由信息，并向提供Topic 服务的 Master Broker ，Slave Broker 建立长链接
且定时向Master Broker ，Slave Broker 发送心跳
Topic
Topic 不可跨实例使用，同一实例中Topic 名称必须唯一
分区
消息的分区，用于存储消息
每个Topic 会有多个分区，每个分区会统计当前消息的总条数为最大位点MaxOffset
一个Topic 由一个或多个分区组成，每个分区中的消息存储于一个或多个Broker上
GroupID
同一个GroupID 不能混用于TCP协议和HTTP协议
实例
同一个实例，需要分别获取TCP协议和Http协议的SDK来使用对应协议的接入点，不能混用
应用场景
应用解耦
消峰填谷
异步通知
大数据处理
分布式事务
IM 实时通信
Cache 同步
移动互联网
IOT 物联网
网络
RocketMQ 只有在公网地域的实例才有TCP协议的公网接入点
Http协议客户端只有在公网地域，没有内网接入点
对应关系
GroupId 和 Topic 的关系是N:N
即一个消费者可以订阅多个topic
同一个Topic 也可以被多个消费者消费
一个生产者可以向多个Topic 发送消息
同一个Topic 也可以接收多个生产者的消息
查询方式
TCP 协议下
支持通过MessageId，MessageKey或Topic 的时间范围查询相关的消息轨迹
HTTP 协议下
仅支持通过MessageId 查询相关的消息轨迹
发送模式
消息重试
一条消息无论重试多少次，这些重试消息的MessageID 不会改变
同步发送
批量消费
仅支持在消息获取方式为Push模式下配置批量消费功能
异步发送
定时/延迟投递
StartDeliverTime 是服务端开始向消费端投递的时间
定时和延时消息的msg.setStartDeliverTime参数需要设置成当前时间戳之后的某个时刻（单位毫秒）。如果被设置成当前时间戳之前的某个时刻，消息将立刻投递给消费者
设置定时和延时消息的投递时间后，依然受3天的消息保存时长限制。例如，设置定时消息5天后才能被消费，如果第5天后一直没被消费，那么这条消息将在第8天被删除
时和延时消息的msg.setStartDeliverTime参数可设置40天内的任何时刻（单位毫秒），超过40天消息发送将失败
如果消费者当前有消息堆积，那么定时和延时消息会排在堆积消息后面，将不能严格按照配置的时间进行投递
消费模式
集群消费
适用于消费端集群化部署，每条消息只需要被处理一次的场景。此外，由于消费者进度在服务端维护，可靠性高。
集群消费模式下，每一条消息只会发送到一台机器上处理
广播消费
适用于消费端集群化部署，每条消息需要被集群下的每个消费者处理的场景
消息队列RocketMQ保证每条消息至少被每台客户端消费一次，但是并不会重投消费失败的消息，因此业务方需要关注消费失败的情况
广播模式出现重复消费的概率稍大于集群模式
广播模式下，不支持顺序消息
消息类型
普通消息
定时/延时消息
顺序消息
全局顺序消息
对于指定的一个Topic ，所有消息按照严格的先入先出（FIFO） 的顺序进行发布和消费
分区顺序消息
对于指定的一个Topic ，所有消息根据 Sharding key 进行区块分区
同一个分区内的消息按照严格的FIFO 顺序进行发布和消费。
事务消息
接入方式
HTTP调用
Http协议 采用HTTP RestFul 标准，方便易用，快速接入，跨网络能力强
SDK调用
TCP
HTTP
每个向消息队列RocketMQ版提交的HTTP请求中都包含Authorization
需要确保需要访问的资源和Http接入点在同一地域
消息队列RocketMQ版提供的HTTP服务通过使用AccessKeyld 和AccessKeySecret进行对称加密的方法来验证请求的发送者身份
TCP协议的客户端和HTTP协议的客户端之间可以实现消息收发，但由于Http协议采用XML序列化，因此消息的属性，内容，tag，key等必须符合XML规范
openAPI Explorer 调用
Open API 是MQ 提供给用户的管控方式，用于实现一系列资源管理和运维功能
跨地域使用消息队列RocketMQ 的场景，推荐使用HTTP协议
死信消息
死信消息不会再被消费者正常消费
一个死信队列对应一个GroupID
如果一个GroupID 未产生死信消息，消息队列不会为其创建对应的死信队列
高级特性
消息重试
顺序消息的重试
当消费者消费消息失败后，MQ 会自动不断进行消息重试（每次间隔时间为1秒） ，这时，应用会出现消息消费被阻塞的情况。因此，建议您使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况
无序消息的重试
当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
重置消费位点
广播模式不支持重置消费位点
消费者必须在线才能重置消费位点
SDK版本过低可能会导致重置消费位点失败
可以选择使用从指定时间点的位点开始消费方式进行重置
ExactlyOnceConsumer 进行消息消费的过程中，不可在控制台使用人工的方式重置消费位点；若主动重置位点到一个已经消费过的位点，则会失去Exactly-Once 的投递语义
消息过滤
MQ允许消费者按照Tag 对消息进行过滤，确保消费者最终只消费到他关心的消息类型
消息去重
At Least Once
RocketMQ 默认支持方式
消息至少投递一次
At Most Once
消息至多投递一次
Exactly Once
消息投递有且仅有一次
消费幂等
当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这整个过程就实现了消息幂等
处理方法
以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息key 设置
0 条评论
下一页
