2.RocketMQ基础设施与特性（你懂RocketMQ吗？下一章show you the code~）

Fa11ing
142 阅读15分钟

第一章为技术对比，第二章为特性简介，第三章纯干货show you the code，第四章为集群搭建。如果文章对您有帮助，请点赞文章，谢谢大家。

基础

RocketMQ服务端两大组件:

NameSrv

类似于kafka强依赖的zookeeper，但是相当的轻量，以至于namesrv并不能像zookeeper一样作为一个单独的组件（服务发现中心，注册中心）工作，在RocketMQ分布式消息系统中，NameSrv主要提供两个功能：

  • 提供服务发现和注册，这里主要是管理Broker，NameSrv接受来自Broker的注册，并通过心跳机制来检测Broker服务的健康性；

  • 提供路由功能，集群(这里是指以集群方式部署的NameSrv)中的每个NameSrv都保存了Broker集群(这里是指以集群方式部署的Broker)中整个的路由信息和队列信息。

    在NameSrv集群中，每个NameSrv都是相互独立的，所以每个Broker需要连接所有的NameSrv，每创建一个新的topic都要同步到所有的NameSrv上。

Broker

主要是负责消息的存储、传递、查询以及高可用(HA)保证等。其由如下几个子模块（源码总体上也是这么拆分的）构成：

  • remoting，是Broker的服务入口，负责客户端的接入（Producer和Consumer）和请求处理
  • client，管理客户端和维护消费者对于Topic的订阅
  • store，提供针对存储和消息查询的简单的API（数据存储在物理磁盘）
  • HA， 提供数据在主从节点间同步的功能特性
  • Index，通过特定的key构建消息索引，并提供快速的索引查询服务

RocketMQ客户端组件:

Producer

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到Broker服务器

RocketMQ提供多种发送方式:

  • 同步发送(sync)
  • 异步发送(async)
  • 单向发送(oneWay)

ProducerGroup

同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致

如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费

Consumer

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序

从用户应用的角度而言提供了两种消费形式：

  • 拉取式消费(PullConsumer):

    应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

  • 推动式消费(PushConsumer):

    该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

    其中RocketMQ-spring的@RocketMQMessageListener默认采用的方式是推模式

ConsumerGroup

同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致

消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易

要注意的是，消费者组的消费者实例必须订阅完全相同的Topic

RocketMQ 支持两种消息模式：

  • 集群消费（Clustering）:

    相同Consumer Group的每个Consumer实例平均分摊消息

  • 广播消费（Broadcasting）:

    相同Consumer Group的每个Consumer实例都接收全量的消息

RocketMQ消息体Message：

Message

消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。

Topic

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位

Tag

为消息设置的标志，用于同一主题下区分不同类型的消息（类似于SubTopic）。

来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。

标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。

消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性 （图片参考网络）

特性

订阅&发布（subscribe&distribute）

发布（distribute）:是指某个生产者向某个topic发送消息

订阅（subscribe）:是指某个消费者订阅了某个topic中带有某些tag的消息，进而从该topic消费数据

消息发送（send message）

通过producer发送消息，在rocketMQ中支持的最基础的3类主要如下：

  • 同步发送 (sync send)：

    指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。

    应用场景： 此种方式应用场景非常广泛，例如重要通知邮件、报名短信通知、营销短信系统等。

  • 异步发送（async send）

    是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。消息队列 RocketMQ 的异步发送，需要用户实现异步发送回调接口（SendCallback）。

    异步发送一般用于链路耗时较长，对 RT 响应时间较为敏感的业务场景，例如批量发货等操作。

    img

    • 单工发送（oneway send）

    发送特点为发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。 此方式发送消息的过程耗时非常短，一般在微秒级别。

    适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。

    img

发送方式发送 TPS发送结果反馈可靠性
同步发送快有不丢失
异步发送快有不丢失
单向发送最快无可能丢失

顺序消费（orderly consume）

消息有序指的是一类消息消费时，能按照发送的顺序来消费。

eg：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。

RocketMQ可以严格的保证消息有序。

顺序消息分 全局顺序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。

  • 全局顺序 ：对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO:First In First Out）的顺序进行发布和消费。

    适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景

  • 分区顺序 ：对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费

    适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

    ps：Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念

消息过滤

RocketMQ的消费者可以根据Tag进行消息过滤，也支持自定义属性过滤。消息过滤目前是在Broker端实现的

  • 优点：减少了对于Consumer无用消息的网络传输
  • 缺点：增加了Broker的负担、而且实现相对复杂（但是使用很简单）

消息可靠性

RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：

  1. Broker非正常关闭
  2. Broker异常Crash
  3. OS Crash
  4. 机器掉电，但是能立即恢复供电情况
  5. 机器无法开机（可能是cpu、主板、内存等关键设备损坏）
  6. 磁盘设备损坏

1)、2)、3)、4) 四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）。

5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。

至少一次

至少一次(At least Once)指每个消息必须投递一次。

Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息。

消息幂等

如果消息重试多次，消费者端对该重复消息消费多次与消费一次的结果是相同的，并且多次消费没有对系统产生副作用，那么我们就称这个过程是消息幂等的。

消息幂等发生的情况

  • producer：

    • producer生产消息，消息成功投递到broker，假设此时broker宕机，导致broker发送ACK（此时ACK指消息发送成功）失败
    • 此时生产者由于未能收到消息发送响应，认为发送失败，因此尝试重新发送消息到broker
    • 当消息发送成功后，在broker中就会存在两条相同内容的消息，最终消费者会拉取到两条内容一样并且Message ID也相同的消息。因此造成了消息的重复。

  • consumer：

    • 当消费者在处理业务完成返回消费状态给broker时，由于网络闪断等异常情况导致未能将消费完成的CONSUME_SUCCESS状态返回给broker。
    • broker为了保证消息被至少消费一次的语义，会在网络环境恢复之后再次投递该条被处理的消息，
    • 最终造成消费者多次收到内容一样并且Message ID也相同的消息，造成了消息的重复。

无论是rocketMQ还是rocketMQ-spring都没有提供消息幂等的自动化实现

依赖于message在broker中的message-id是不可靠的：因为message-id本身有冲突的可能。所以这一块只能由业务层进行实现

因此消息幂等必须由由业务层收到消息后进行处理

无论怎样引入缓存机制，最终都需要通过业务唯一id，例如订单流水号来进行幂等判定，再加上消息记录表进行追溯处理

回溯消费

回溯消费是指Consumer已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker在向Consumer投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ支持按照时间回溯消费，时间维度精确到毫秒

事务消息

RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败

定时消息

定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic。

broker有配置项messageDelayLevel

默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18个level。

可以配置自定义messageDelayLevel。

注意，messageDelayLevel是broker的属性，不属于某个topic。

发消息时，设置delayLevel等级即可：msg.setDelayLevel(level)。level有以下三种情况：

  • level == 0，消息为非延迟消息
  • 1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s
  • level > maxLevel，则level== maxLevel，例如level==20，延迟2h

定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一个queue只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。

broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic。

需要注意的是，定时消息会在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高。

消息重试

Consumer消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer消费消息失败通常可以认为有以下几种情况：

  • 由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被注销，无法充值）等。这种错误通常需要跳过这条消息，再消费其它消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过10秒后再重试。
  • 由于依赖的下游应用服务不可用，例如db连接不可用，外系统网络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用sleep 30s，再消费下一条消息，这样可以减轻Broker重试消息的压力。

RocketMQ会为每个消费组都设置一个Topic名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个Topic的重试队列是针对消费组，而不是针对每个Topic设置的），用于暂时保存因为各种异常而导致Consumer端无法消费的消息。考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大。RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行Delay后重新保存至“%RETRY%+consumerGroup”的重试队列中。

消息重投

producer在发送消息时，同步消息失败会重投，异步消息有重试，oneway没有任何保证。消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在RocketMQ中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer负载变化也会导致重复消息。如下方法可以设置消息重试策略：

  • retryTimesWhenSendFailed:同步发送失败重投次数，默认为2，因此生产者会最多尝试发送retryTimesWhenSendFailed + 1次。不会选择上次失败的broker，尝试向其他broker发送，最大程度保证消息不丢。超过重投次数，抛出异常，由客户端保证消息不丢。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。
  • retryTimesWhenSendAsyncFailed:异步发送失败重试次数，异步重试不会选择其他broker，仅在同一个broker上做重试，不保证消息不丢。
  • retryAnotherBrokerWhenNotStoreOK:消息刷盘（主或备）超时或slave不可用（返回状态非SEND_OK），是否尝试发送到其他broker，默认false。十分重要消息可以开启。

流量控制(尝试与Sentinel联动)

生产者流控，因为broker处理能力达到瓶颈；消费者流控，因为消费能力达到瓶颈。

生产者流控：

  • commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，返回流控。
  • 如果开启transientStorePoolEnable == true，且broker为异步刷盘的主机，且transientStorePool中资源不足，拒绝当前send请求，返回流控。
  • broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，返回流控。
  • broker通过拒绝send 请求方式实现流量控制。

注意，生产者流控，不会尝试消息重投。

消费者流控：

  • 消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。
  • 消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。
  • 消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000。

消费者流控的结果是降低拉取频率。

死信队列

死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

RocketMQ将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费。

avatar
文章
阅读
粉丝